INFORMATION PROCESSING METHOD , INFORMATION PROCESSING 
APPARATUS AND RECORDING MEDIUM 

CROSS-REFERENCE TO RELATED APPLICATIONS 

[0001] The present application claims priority from 

Japanese application Nos . 2001-033114 filed February 9, 2001 
and 2001-094803 filed March 29, 2001, the disclosures of which 
are hereby incorporated by reference herein. 

BACKGROUND OF THE INVENTION 

[0002] In general, the present invention relates to an 

information processing method, an information processing 
apparatus, a program storage medium and a program. More 
particularly, the present invention relates to an information 
processing method and an information processing apparatus 
which are used for preventing content from being copied and 
used illegally without a license from the owner of the 
copyright in the content, a program for implementing the 
information processing method and a program storage medium for 
storing the program. 

[0003] In recent years, users have provided musical data 

they own to other users and have received musical data they do 
not own from other users through the Internet in content- 
exchanging system that allows a plurality of users to exchange 
musical data free of charge. 

[0004] in such content-exchanging system, theoretically, 

music or another content owned by one user can thus be enjoyed 
by other users. Therefore, many users do not have to purchase 



such a piece of music or such content. As a result, since such 
a piece of music or such content does not sell well, the owner 
of the copyright in the content loses the opportunity to gain 
a royalty for the use of the piece of music or the content 
accompanying the sales of the piece of music or the content. 
[0005] In society, there is thus a demand to prevent 

content from being copied and used illegally. 



SUMMARY OF THE INVENTION 

[0006] It is thus an object of the present invention 

^; addressing the problems described above to reliably prevent 

Q content from being used illegally. 

r y [0007] In accordance with an aspect of the present 

□ invention, there is provided an information processing 

iJ 

apparatus for allowing usage of content by requiring a license 

■3 

ill for using the content. The information processing apparatus 

ill includes a content storage unit operable to store license- 

a 

|1y identification information for specifying the license for 

using the content, encrypted data of the content and key 
information required for decrypting the encrypted data of the 
content; a license storage unit operable to store the license 
for using the content, including content-specifying 
information for specifying the content, the use of which is 
allowed by the license; a judgment unit operable to determine 
whether the license for using the content has been stored in 
the license storage unit; and a decryption unit operable to 
decrypt the encrypted data of the content if the license for 
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using the content has been stored in the license storage unit. 
[0008] The information processing apparatus further 

includes a transmitter operable to transmit a request for the 
license to a license server, the license request including the 
license-identification information; and a receiver operable to 
receive the license transmitted by the license server. The 
received license may be stored in the license storage unit. 
[0009] The information processing apparatus further 

includes a reproducing unit operable to reproduce the data of 
the content decrypted by the decryption unit, wherein the data 
of the content is text data, image data, audio data, moving- 
picture data or combinations thereof. 

[0010] The information processing apparatus further 

includes a device-node-key storage unit operable to store a 
device node key. The key information includes an EKB (Enabling 
Key Block) . The decryption unit is operable to decrypt the EKB 

(Enabling Key Block) using the device node key to obtain a 
root key, and to decrypt the data of the content using the 
root key. 

[0011] In the information processing apparatus, the key 

information further includes a content key encrypted using the 
root key. The data of the content is encrypted using the 
content key. The decryption unit is operable to decrypt the 
encrypted data of the content using the root key. 

[0012] In the information processing apparatus, the 

license further includes usage-condition information showing a 
condition for using the content, the use of which is allowed 



by the license. 

[0013] In the information processing apparatus, the 

license further includes an electronic signature signed by 
using a secret key of a license server. 

[0014] The information processing apparatus further has a 

terminal-ID storage unit operable to store terminal- 
identification information identifying the information 
processing apparatus. The license reguest further includes the 
terminal identification information, and the received license 
includes a terminal ID. The judgment unit compares the 
terminal ID in the received license with the terminal- 
identification information stored in the terminal-ID storage 
unit and determines that the received license is the license 
for using the content only if the terminal ID in the received 
license matches the terminal-identification information stored 
in the terminal-ID storage unit. 

[0015] In accordance with another aspect of the present 

invention, there is provided an information processing method 
for allowing a user to use content by reguiring the user to 
have a license for using the content. The information 
processing method includes storing license-identification 
information for specifying the license for using the content, 
encrypted data of the content and key information required for 
decrypting the encrypted data of the content; storing the 
license for using the content in a license storage unit, the 
license including content-specifying information for 
specifying the content, the use of which is allowed by the 



license; determining whether the license for using the content 
has been stored in the license storage unit; and decrypting 
the encrypted data of the content if the license for using the 
content has been stored in the license storage unit. 
[0016] In accordance with a further aspect of the present 

invention, there is provided a recording medium recorded with 
a program to be executed by a computer for carrying out 
processing to allow a user to use content by requiring the 
user to have a license for using the content. The program 
includes storing license-identification information for 
specifying the license for using the content, encrypted data 
of the content and key information required for decrypting the 
encrypted data of the content; storing the license for using 
the content in a license storage unit, the license including 
content-specifying information for specifying the content, the 
use of which is allowed by the license; determining whether 
the license for using the content has been stored in the 
license storage unit; and decrypting the encrypted data of the 
content if the license for using the content has been stored 
in the license storage unit. 

[0017] The program or a portion of the program may be 

encrypted. 

[0018] In accordance with a still further aspect of the 

present invention, there is provided a license server for 
issuing a license for allowing the use of content. The license 
server includes a license storage unit operable to store the 
license, the license including content-specifying information 
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for specifying the content, the use of which is allowed by the 
license; and terminal-identification information for 
identifying an information processing apparatus; a receiver 
operable to receive a request for the license from the 
information processing apparatus, the license request 
including license-identification information for identifying 
the license; an extraction unit operable to extract the 
license identified by the license-identification information 
from the license storage unit; a processor operable to add the 
terminal-identification information to the extracted license; 
a signature unit operable to put a signature on the extracted 
license including the terminal-identification information 
using a secret key of the license server; and a transmitter 
operable to transmit the extracted license with the signature 
thereon to the information processing apparatus. 
[0019] In accordance with a still further aspect of the 

present invention, there is provided a method for issuing a 
license for allowing the use of content. The method includes 
storing the license in a license storage unit, the license 
including content-specifying information for specifying the 
content, the use of which is allowed by the license, and 
terminal-identification information for identifying an 
information processing apparatus; receiving a request for the 
license from the information processing apparatus, the license 
request including license-identification information for 
identifying the license; extracting the license stored in the 
license storage unit and identified by the license- 
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identification information; adding the terminal-identification 
information to the extracted license; putting a signature on 
the extracted license including the terminal-identification 
information using a secret key; and transmitting the extracted 
license with the signature thereon to the information 
processing apparatus. 

[0020] In accordance with a still further aspect of the 

present invention, there is provided a recording medium 
recorded with a program to be executed by a computer for 
carrying out processing to issue a license for allowing the 
use of content. The program includes storing the license in a 
license storage unit, the license including content- 
identification information for specifying the content, the use 
of which is allowed by the license, and terminal- 
identification information for identifying an information 
processing apparatus; receiving a request for the license from 
the information processing apparatus, the license request 
including license-identification information for identifying 
the license; extracting the license stored in the license 
storage unit and identified by the license-identification 
information; adding the terminal-identification information to 
the extracted license; putting a signature on the extracted 
license including the terminal-identification information 
using a secret key; and transmitting the extracted license 
with the signature thereon to the information processing 
apparatus . 

[0021] In the information processing method, the 
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information processing apparatus and the recording medium 
recorded with the program which are provided by the present 
invention, content is decrypted and can be used on condition 
that the user has a license for using the content. 
[0022] In the license server and the information 

processing method provided by the present invention, a valid 
license is issued only to a specific information processing 
apparatus . 



BRIEF DESCRIPTION OF THE DRAWINGS 

[0023] Fig. 1 is a schematic diagram showing the 

configuration of content-exchanging system to which the 
present invention is applied; 

[0024] Fig. 2 is a block diagram showing the 

configuration of a client shown in Fig. 1; 

[0025] Fig. 3 is a flowchart used for explaining 

processing carried out by the client shown in Fig. 1 to 
download content; 

[0026] Fig. 4 is a flowchart used for explaining 

processing carried out by content server shown in Fig. 1 to 
provide a client with content; 

[0027] Fig. 5 is a diagram showing a typical format of 

data generated at step S2 6 of the flowchart shown in Fig. 4; 
[0028] Fig. 6 is a flowchart used for explaining 

processing carried out by the client shown in Fig. 1 to play 
back content; 

[0029] Fig. 7 is a flowchart used for explaining details 
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of processing carried out at step S43 of the flowchart shown 
in Fig. 6 to acguire a license; 

[0030] Fig. 8 is a diagram showing the configuration of a 

license; 

[0031] Fig. 9 is a flowchart used for explaining 

processing carried out by a license server shown in Fig. 1 to 
issue a license; 

[0032] Fig. 10 is a flowchart used for explaining details 

of processing carried out at step S45 of the flowchart shown 
in Fig. 6 to update a license; 

[0033] Fig. 11 is a flowchart used for explaining 

processing carried out by the license server shown in Fig. 1 
to update a license; 

[0034] Fig. 12 is an explanatory diagram showing an 

organization of keys; 

[0035] Fig. 13 is an explanatory diagram showing category 

nodes ; 

[0036] Fig. 14 is a diagram concretely showing the 

typical association of nodes with devices; 

[0037] Figs. 15A and 15B are explanatory diagrams showing 

the configuration of an EKB (Enabling Key Block) ; 

[0038] Fig. 16 is an explanatory diagram showing use of 

the EKB (Enabling Key Block); 

[0039] Fig. 17 is an explanatory diagram showing a 

typical format of the EKB (Enabling Key Block) ; 

[0040] Figs. 18A to 18C are explanatory diagrams showing 

the configuration of tags in an EKB (Enabling Key Block) ; 



[0041] Fig. 19 is an explanatory diagram showing 

processing to decrypt content by using a DNK (Device Node 
Key) ; 

[0042] Fig. 20 is a diagram showing a typical EKB 

(Enabling Key Block) ; 

[0043] Fig. 21 is an explanatory diagram showing 

assignment of a plurality of contents to a device; 
[0044] Fig. 22 is an explanatory diagram showing license 

categories ; 

[0045] Fig. 23 is a flowchart used for explaining a 

ripping process carried out by a client; 

[0046] Fig. 2 4 is an explanatory diagram showing the 

configuration of a watermark; 

[0047] Fig. 25 is an explanatory diagram showing a 

typical format of content; 

[0048] Fig. 2 6 is a diagram showing a typical certificate 

of a disclosed key; 

[0049] Fig. 27 is an explanatory diagram showing 

distribution of content; 

[0050] Fig. 28 is a flowchart used for explaining 

processing carried out by a client to check out content; 

[0051] Fig. 2 9 is an explanatory diagram showing typical 

tracing of an EKB (Enabling Key Block) by using tags; 

[0052] Fig. 30 is a diagram showing a typical 

configuration of the EKB (Enabling Key Block) ; 

[0053] Fig. 31 is an explanatory diagram showing the 

configuration of a mark; 
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[0054] Fig. 32 is a flowchart used for explaining 

processing carried out by a client to purchase a license; 
[0055] Fig. 33 is a flowchart used for explaining 

processing carried out by a license server to purchase a 
license; 

[0056] Fig. 34 is an explanatory diagram showing the 

configuration of a mark; 

[0057] Fig. 35 is a flowchart used for explaining 

processing carried out by a client to catalog a certificate of 
the client; 

h 4 [0058] Fig. 36 is a flowchart used for explaining 

□ processing carried out by content server to catalog the 

fy certificate; 

Q [0059] Fig. 37 is a diagram showing a typical certificate 

■i of a group; 

fy [0060] Fig. 38 is a flowchart used for explaining 

□ 

:Ti processing carried out by content server to form a group; 

py [0061] Fig. 39 is a diagram showing typical processing to 

encrypt content key; 

[0062] Fig. 40 is a flowchart used for explaining 

processing carried out by a client pertaining to a group; 

[0063] Fig. 41 is a flowchart used for explaining 

processing carried out by a client to check out a license to 
another client; 

[0064] Fig. 42 is a flowchart used for explaining 

processing carried out by a client to receive a license 
checked out by another client from the other client; 



[0065] Fig. 43 is a flowchart used for explaining 

processing carried out by a client to play back a license 
checked out by another client; 

[0066] Fig. 44 is a flowchart used for explaining 

processing carried out by a client to check in a license 
checked out by another client; 

[0067] Fig. 45 is a flowchart representing processing 

carried out by a client issuing a request for the processing 
to check in a license to another client carrying out the 
license-check-in processing represented by the flowchart shown 
in Fig. 44; 

[0068] Fig. 46 is an explanatory diagram showing 

generation of a MAC (Message Authentication Code) ; 

[0069] Fig. 47 is a flowchart used for explaining 

processing to decrypt an ICV (Integrity Check Value) 
generation key; 

[0070] Fig. 48 is a flowchart used for explaining other 

processing to decrypt the ICV generation key; 

[0071] Figs. 4 9A and 4 9B are explanatory diagrams showing 

ICV-based management of operations to copy a license; and 
[0072] Fig. 50 is an explanatory diagram showing 

management of licenses. 

DETAILED DESCRIPTION 

[0073] Fig. 1 is a block diagram showing the 

configuration of content-exchanging system to which the 
present invention is applied. Clients 1-1 and 1-2 are 
12 



connected to the Internet 2. In the following description, the 
clients 1-1 and 1-2 are each denoted by generic reference 
numeral 1 if it is not necessary to distinguish the clients 1- 

1 and 1-2 from each other. In this example, only two clients 
are shown. However, any arbitrary number of clients can be 
connected to the Internet 2 . 

[0074] In addition, content server 3, a license server 4 

and a charging server 5 are also connected to the Internet 2. 
The content server 3 provides contents to the client 1, and 
the license server 4 provides the client 1 with a license 
required for using content provided by the content server 3. 
The charging server 5 carries out a charging process for the 
client 1 when the client 1 receives a license from the license 
server 4. 

[0075] Any arbitrary number of content servers 3, license 

servers 4 and charging servers 5 can be connected to the 
Internet 2 . 

[0076] Fig. 2 is a block diagram showing the 

configuration of the client 1. In the client 1 shown in Fig. 2, 
a CPU (Central Processing Unit) 21 carries out various kinds 
of processing in accordance with programs stored in a ROM 

(Read-Only Memory) 22 and programs loaded from a storage unit 

2 8 into a RAM (Random-Access Memory) 23. A timer 2 0 measures 
the lapse of time and supplies a result of measurement to the 
CPU 21. The RAM 23 is also used for storing data required by 
the CPU 21 in the execution of the various kinds of processing 
[0077] An encryption and decryption unit 24 encrypts 
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content and decrypts already encrypted content. A codec unit 
25 encodes content in accordance with an ATRAC (Adaptive 
Transform Acoustic Coding) -3 system and supplies the encoded 
content to a semiconductor memory 4 4 to be stored therein. The 
semiconductor memory 44 is connected to a drive 30. An example 
of the semiconductor memory 44 is a Memory Stick (a trademark) . 
In addition, the codec unit 25 decodes encoded data read out 
from the semiconductor memory 44 through the drive 30. 
[0078] The CPU 21, the ROM 22, the RAM 23, the encryption 

and decryption unit 24, and the codec unit 25 are connected to 
each other by a bus 31. The bus 31 is also connected to an 
input/output interface 32. 

[0079] The input/output interface 32 is connected to an 

input unit 2 6, an output unit 27, the storage unit 2 8 and a 
communication unit 29. The input unit 2 6 includes a keyboard 
and a mouse. The output unit 27 includes a speaker and a 
display unit such as a CRT or an LCD. The communication unit 
2 9 includes a modem and a terminal adaptor. The communication 
unit 2 9 carries out communications through the Internet 2. To 
be more specific, the communication unit 2 9 exchanges analog 
and digital signals with other clients. 

[0080] If necessary, the input/output interface 32 is 

also connected to the drive 30, on which a proper storage 
medium such as a magnetic disk 41, an optical disk 42, a 
magneto-optical disk 43 or the semiconductor memory 44 is 
mounted. If necessary, a computer program can thus be read out 
from the storage medium and installed in the storage unit 28. 
14 



[0081] The configurations of the content server 3, the 

license server 4 and the charging server 5 are not shown in 
the figures. However, the content server 3, the license server 
4 and the charging server 5 are each a computer having a 
configuration basically identical with the client 1 shown in 
Fig. 2. For this reason, some of the reference numerals shown 
in the configuration of Fig. 2 are used for denoting identical 
components employed in the content server 3, the license 
server 4 and the charging server 5 in the following 
description . 

[0082] By referring to the flowchart shown in Fig. 3, the 

following description explains the processing to provide 
content from the content server 3 to the client 1. 
[0083] As shown in the figure, the flowchart begins with 

a step SI at which the user enters a command to access the 
content server 3 by operating the input unit 26. In accordance 
with the command, the CPU 21 controls the communication unit 
2 9 to access the content server 3 through the Internet 2. Then, 
at the next step S2, when the user specifies a desired content 
by operating the input unit 2 6, the CPU 21 accepts the 
specification. The communication unit 2 9 informs the content 
server 3 of the specified content through the Internet 2. 
Notified of the specified content, the content server 3 
transmits encoded data of the content in a process represented 
by the flowchart shown in Fig. 4, as will be described later. 
Subsequently, at the next step S3, the CPU 21 receives the 
content through the communication unit 29. Then, at the next 
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step S4, the encoded data of the content is stored in a hard 
disk of the storage unit 28. 

[0084] With reference to the flowchart shown in Fig. 4, 

the following description explains the processing carried out 
by the content server 3 to transmit the content requested by 
the client 1 at the step S2 . It should be noted that, since 
the content server 3 has a configuration comprising components 
identical with those employed in the client 1, the same 
reference numerals as those shown in Fig. 2 are used for 
denoting identical components in the following description. 
[0085] As shown in Fig. 4, the flowchart begins with a 

step S21 at which the CPU 21 employed in the content server 3 
is waiting for the content server 3 to be accessed by the 
communication unit 29 by way of the Internet 2. When access is 
determined to have been made, the flow of the processing goes 
on to a step S22 at which information transmitted by the 
client 1 to specify the content is acquired. The information 
specifying the content is transmitted by the client 1 at the 
step S2 of the flowchart shown in Fig. 3. 

[0086] Then, at the next step S23, the CPU 21 employed in 

the content server 3 reads out the content specified by the 
information acquired at the step S22 from the storage unit 28. 
The content read out from the storage unit 2 8 is selected from 
among contents stored in the storage unit 28. Subsequently, at 
the next step S2 4, the CPU 21 supplies the content read out 
from the storage unit 2 8 to the encryption and decryption unit 
24, which then encrypts the content by using content key Kc. 
16 



[0087] Since the contents stored in the storage unit 2 8 

have been encoded by the codec unit 2 5 in accordance with the 
ATRAC 3 system, the encryption and decryption unit 2 4 encrypts 
an encoded content received from the CPU 21. 

[0088] It should be noted that the storage unit 28 can 

also be used for storing contents which have been encrypted in 
advance. In this case, the processing carried out at the step 
S24 can be eliminated. 

[0089] Then, at the next step S25, the CPU 21 employed in 

the content server 3 adds keys and a license ID to the header 
M" of a format in which the encrypted content is to be 

g 

3 transmitted. Required for decrypting the encrypted data, the 

Hyi keys are an EKB and a key K EKB c (Kc) , which will be described 

□ later by referring to Fig. 5. The license ID is used to 

:. ; identify a license necessary for using the content, 

ny Subsequently, at the next step S2 6, the CPU 21 employed in the 

m content server 3 transmits formatted data to the client 1 

5 

nil through the communication unit 29 and the Internet 2. The 

formatted data is a result of formatting the content encrypted 
at the step S2 4 and the header, including the key and the 
license ID which are added to the header at the step S25. 
[0090] Fig. 5 is a diagram showing the format of the 

content received by the client 1 from the content server 3. As 
shown in the figure, the format comprises a header and a data 
portion . 

[0091] The header comprises content information, DRM 

(Digital Right Management) information, a license ID, an EKB 



(Enabling Key Block) and a key K EK bc (Kc) , which is content key 
Kc encrypted by a key K EK bc generated from the EKB . It should 
be noted that the EKB will be explained later by referring to 
Fig. 15. 

[0092] The content information includes content ID CID 

and information on a codec system. The content ID CID is 
identification for identifying the formatted content in the 
data portion of the format. 

[0093] The DRM information comprises the content's usage 

rules and status. The DRM information also includes a URL 
(Uniform Resource Locator) . The usage rules and status 
typically include the number of times the content has been 
played back and the number of times the content has been 
copied . 

[0094] The URL is an address which may be accessed in 

order to acquire a license prescribed by the license ID. More 
specifically, the URL is the address of the license server 4 
for providing a required license in the case of the content- 
exchanging system shown in Fig. 1. The license ID is 
identification for identifying the license required to use the 
content recorded as the data portion of the format. 

[0095] The data portion of the format comprises any 

arbitrary number of encrypted blocks. Each of the encrypted 
blocks comprises an initial vector IV, a seed and encrypted 
data Ek'c (data), which is a result of encrypting the content 
by using a key K'c. 

[0096] As shown in the following formula, the key K'c is 
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a result of processing carried out by applying the content key 
Kc and the seed to a hash function. The seed is a value set at 
random. 

i. K'c = Hash (Kc, Seed) 
[0097] The initial vector IV and the seed vary depending 

on the encrypted block. 

[0098] The content is encrypted in 8-byte units. The 8 

bytes at a current stage are encrypted by using the result of 
encryption of 8 bytes at the preceding stage in a CBC (Cypher 
Block Chaining) mode. 

[0099] In the CBC mode, when the first 8 bytes of content 

are encrypted, no encryption of 8 bytes is carried out at the 
preceding stage so that the result of preceding-stage 
encryption is not available. Thus, the first 8 bytes of the 
content are encrypted by using the initial vector IV as an 
initial value. 

[0100] Therefore, even if an encrypted block of content 

encrypted in the CBC mode can be decoded, the decoding result 
of the block may not necessarily make another encrypted block 
easy to decode. 

[0101] It should be noted that the encryption process 

will be explained later in detail by referring to Fig. 46. The 
encryption system, however, is not limited thereto. 
[0102] As described above, the client 1 is allowed to 

freely acquire content from the content server 3 free of 
charge. Thus, a large number of contents can be distributed. 
[0103] When using acquired content, however, the client 1 
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needs to have a license. The following description explains 
the processing carried out by the client 1 to play back 
content with reference to the flowchart shown in Fig. 6. 
[0104] As shown in the figure, the flowchart begins with 

a step S41 at which the user operates the input unit 2 6 to 
specify a desired content and the CPU 21 employed in the 
client 1 acquires the identification of the content (CID) . The 
identification comprises the title of the content, a number 
assigned to the content and the like. It should be noted that 
a number is assigned to each stored content. 

[0105] When content is desired, the CPU 21 reads out a 

license ID for the content. To be more specific, the license 
ID identifies a license required to utilize the content. As 
shown in Fig. 5, the license ID is included in the header of 
the encrypted content. 

[0106] Then, at the next step S42, the CPU 21 forms a 

judgment as to whether the license indicated by the license ID 
obtained at the step S41 has been acquired by the client 1 and 
stored in the storage unit 28. If the license indicated by the 
license ID has not been acquired by the client 1, the flow of 
the processing goes on to a step S43 at which the CPU 21 
carries out processing to acquire the license. Details of the 
processing to acquire the license will be explained later by 
referring to the flowchart shown in Fig. 7. 

[0107] If the outcome of the judgment formed at the step 

S42 indicates that the license identified by the license ID 
has been acquired by the client 1 and stored in the storage 
20 



unit 28, or if the license can be obtained as a result of the 
processing carried out at the step S43 to acquire the license, 
the flow of the processing goes on to a step S44 at which the 
CPU 21 forms a judgment as to whether the acquired license is 
still in its term of validity. It is possible to determine 
whether the acquired license is still in its term of validity 
by comparing a term of validity prescribed in the license 
(which will be described in Fig. 8) with the present date and 
time measured by the timer 20. If the term of validity of the 
license has already expired, the flow of the processing goes 
on to a step S45 at which the CPU 21 carries out processing to 

Q 

update the license. Details of the processing to update the 
license will be explained later by referring to the flowchart 
0 shown in Fig. 8. 

[0108] If the outcome of the judgment formed at the step 

"J 

p S44 indicates that the acquired license is still in its term 

of validity, or if the license can be updated at the step S45, 
the flow of the processing goes on to a step S46 at which the 
CPU 21 reads out the encrypted content from the storage unit 
28 and stores the content into the RAM 23. Then, at the next 
step S47, the CPU 21 supplies the data of the encrypted 
content stored in the RAM 23 to the encryption and decryption 
unit 2 4 in encrypted-block units included in the data portion 
shown in Fig. 5. The encryption and decryption unit 2 4 then 
decrypts the encrypted content by using the content key Kc . 
[0109] A typical method of acquiring the content key Kc 

will be described later by referring to Fig. 15. The key K EKB c 
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included in the EKB shown in Fig. 5 can be obtained by using a 
device node key (DNK) shown in Fig. 8. The content key Kc is 
then obtained from the data K EKBC (Kc) by using the key K EK bc- 
[0110] Subsequently, at the next step S48, the CPU 21 

supplies the content decrypted by the encryption and 
decryption unit 2 4 to the codec unit 25, which then decodes 
the content. Subsequently, the CPU 21 supplies data decoded by 
the codec unit 25 to the output unit 27 by way of the 
input/output interface 32. The data is subjected to D/A 
conversion before being output to a speaker. 

I'lT [0111] With reference to the flowchart shown in Fig. 7, 

the following description explains the processing carried out 
at the step S43 of the flowchart shown in Fig. 6 to acquire a 

Q license. 

;!L [0112] The client 1 acquires beforehand service data 

Hij cataloged in advance in the license server 4. The service data 

includes a leaf ID, a DNK (Device Node Key), a pair of secret 
ill and disclosed keys pertaining to the client 1, a disclosed key 

of the license server 4 and certificates for the disclosed 

keys . 

[0113] A leaf ID is an ID assigned uniquely to each 

client 1. A DNK (Device Node Key) is a key required for 
decrypting an encrypted content key Kc included in the EKB 

(Enabling Key Block) for the license, as will be described 
later by referring to Fig. 12. 

[0114] As shown in Fig. 7, the flowchart begins with a 

step S61 at which the CPU 21 acquires a URL for the ID of the 



license being processed from the header shown in Fig. 5. As 
described earlier, this URL is an address which is to be 
accessed in order to acquire the license identified by the 
license ID included in the header. Then, at the next step S62, 
the CPU 21 accesses the URL acquired at the step S61. More 
specifically, the license server 4 is accessed through the 
communication unit 29 and the Internet 2. At that time, the 
license server 4 requests the client 1 to transmit a user ID, 
a password and license-specifying information specifying a 
license to be purchased. This license is required to utilize 
the content. This request is made at a step S102 of the 
flowchart shown in Fig. 9, as will be described later. The CPU 
21 displays this request on the display device of the output 
unit 27. In response to this request, the user of the client 1 
operates the input unit 2 6 to enter a user ID, a password and 
license-specifying information. It should be noted that the 
user obtained the user ID and the password previously by 
accessing the license server 4 through the Internet 2. 
[0115] Subsequently, at the next steps S63 and S64, the 

CPU 21 receives the license-specifying information, the user 
ID and the password, which have been entered from the input 
unit 26 by the user. Then, at the next step S65, the CPU 21 
controls the communication unit 29 to transmit a license 
request including the user ID, the password, the license- 
specifying information and a leaf ID to the license server 4 
by way of the Internet 2 . The leaf ID is information included 
in the service data to be described later. 
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[0116] As will be described later, at a step S109 of the 

flowchart shown in Fig. 9, the license server 4 transmits a 
license based on the user ID, the password and the license- 
specifying information. As an alternative, the license server 
4 carries out error processing at a step S112 of the flowchart 
shown in Fig. 9 instead of transmitting a license in case a 
condition is not met. 

[0117] The processing then goes on to a step S66 to form 

a judgment as to whether the license has been received from 
the license server 4. If the license has been received, the 
flow of the processing goes on to a step S67 at which the CPU 
21 supplies the license to the storage unit 28 to be stored 
therein . 

[0118] If the outcome of the judgment formed at the step 

S66 indicates that the license was not received, on the other 
hand, the flow of the processing goes on to a step S68 at 
which the CPU 21 carries out error processing. More 
particularly, the CPU 21 inhibits the processing to play back 
the content since the CPU 21 has failed to obtain the license 
for using the content. 

[0119] As described above, the client 1 is capable of 

using content by obtaining a license indicated by a license ID 
included in the content. 

[0120] It should be noted that the processing to acquire 

a license as represented by the flowchart shown in Fig. 7 can 
also be carried out in advance before the user acquires the 
content . 
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[0121] As shown in Fig. 8, the license supplied to the 

client 1 includes usage conditions and a leaf ID. The usage 
conditions are information including a deadline by which the 
content must be downloaded as allowed by the license, an upper 
limit of the number of times the content can be copied as 
allowed by the license or the maximum number of allowed copy 
operations, the number of checkouts, the maximum number of 
checkouts, a right to record the content on a CD-R, the number 
of times the content can be copied to a PD (Portable Device), 
a right to allow the license to use the content to be changed 
to license ownership status (or purchased-license status) and 
a duty of making a usage log. 

[0122] By referring to the flowchart shown in Fig. 9, the 

following description explains processing carried out by the 
license server 4 to transmit a license to the client 1 in 
response to the processing carried out by the client 1 to 
acquire the license as represented by the flowchart shown in 
Fig. 7. It should be noted that, also in this case, since the 
license server 4 has a configuration comprising components 
identical with those employed in the client 1, the same 
reference numerals as those shown in Fig. 2 are used for 
denoting identical components in the following description. 
[0123] As shown in the figure, the flowchart begins with 

a step S101 at which the CPU 21 employed in the license server 
4 waits for the license server 4 to be accessed by the client 
1. As the client 1 accesses the license server 4, the flow of 
the processing goes on to a step S102 at which the license 
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server 4 requests the client 1 to transmit license-specifying 
information (a license ID), a user ID and a password. Then, 
the CPU 21 employed in the license server 4 receives the user 
ID, the password, the leaf ID and the license ID from the 
client 1 through the communication unit 29 at the step S65 of 
the flowchart shown in Fig. 7, and carries out processing to 
accept them. 

[0124] Then, at the next step S103, the CPU 21 employed 

in the license server 4 accesses the charging server 5 through 
the communication unit 2 9 in order to make a request for 
M= processing to examine the user identified by the user ID and 

□ the password. When receiving the request for such an 

: 4 

U examination from the license server 4 through the Internet 2, 

U, 

□ the charging server 5 checks the past payment history of the 
user identified by the user ID and the password in order to 

Q 

ry determine whether there is a record indicating that the user 

00 did not pay for requested licenses in the past. If there is no 

;ij record indicating that the user did not pay for requested 

licenses in the past, the charging server 5 transmits an 
examination result indicating that the granting of a license 
is approved. If, on the other hand, there is a record 
indicating that the user did not pay for requested licenses in 
the past or another bad record, the charging server 5 
transmits an examination result indicating that the granting 
of a license is not approved. 

[0125] Subsequently, at the next step S104, the CPU 21 

employed in the license server 4 forms a judgment as to 
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whether the examination result received from the charging 
server 5 indicates that the granting of a license is approved 
or disapproved. If the granting of a license is approved, the 
flow of the processing goes on to a step S105 at which the CPU 
21 selects the license specified by the license-specifying 
information received in the processing carried out at the step 
S102 from among licenses stored in the storage unit 28, and 
reads out the selected license from the storage unit 28. Each 
license stored in the storage unit 2 8 includes information 
including the license ID, a version, a creation date and time 
and a term of validity. Then, at the next step S106, the CPU 
21 adds the received leaf ID to the license. Furthermore, at 
the next step S107, the CPU 21 selects a usage condition 
associated with the license selected at the step S105. If a 
usage condition was found at the step S102 to have been 
specified by the user, if necessary, the usage condition 
specified by the user is added to a usage condition prepared 
in advance. The CPU 21 then adds the selected usage condition 
to the license. 

[0126] Then, at the next step S108, the CPU 21 puts a 

digital signature on the license by using a secret key of the 
license server 4 to produce a license with a configuration 
like the one shown in Fig. 8. 

[0127] Subsequently, at the next step S109, the CPU 21 

employed in the license server 4 transmits the license with a 
configuration like the one shown in Fig. 8 from the 
communication unit 29 to the client 1 by way of the Internet 2 
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[0128] Then, at the next step S110, the CPU 21 employed 

in the license server 4 stores the license transmitted in the 
processing carried out at the step S109 in the storage unit 28 
by associating the license with the user ID and the password, 
which were acquired in the processing carried out at the step 
S102. As described above, the license includes a usage 
condition and a leaf ID. Subsequently, at the next step Sill, 
the CPU 21 carries out a charging process. More particularly, 
the CPU 21 requests the charging server 5 through the 
communication unit 2 9 to carry out a charging process for the 
user identified by the user ID and the password. The charging 
server 5 carries out the charging process based on the request. 
The processing carried out by the license server 4 is then 
finished. 

[0129] If the user does not pay the amount of money 

determined by the charging process, the user will not be 
granted a license in the future, even if the granting of a 
license is requested as described above. That is to say, in 
the case of such a user, the charging server 5 will not 
approve the granting of a license as a result of examining 
whether to grant a license to the user. In other words, the 
flow of the processing will go from the step S104 to a step 
S112 at which the CPU 21 employed in the license server 4 
carries out an error-handling process. More specifically, the 
CPU 21 controls the communication unit 29 to output a message 
informing the client 1 accessing the license server 4 that a 
license cannot be granted. The processing carried out by the 
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license server 4 is then finished. 

[0130] In this case, the client 1 cannot use the content 

or is not capable of decrypting the encrypted data of the 
content because the client 1 has failed to obtain a license as 
described above. 

[0131] Fig. 10 is a flowchart used for explaining details 

of the processing carried out at the step S45 of the flowchart 
shown in Fig. 6 to update a license. The processing carried 
out at steps S131 to S135 is basically the same as the 
processing carried out at the respective steps S61 to S65 of 
the flowchart shown in Fig. 7. At the step S133, however, the 
CPU 21 acquires the license ID of a license to be updated 
instead of the license ID of a purchased license. Then, at the 
step S135, the CPU 21 transmits a user ID and a password along 
with the license ID of the license to be updated to the 
license server 4. 

[0132] In response to what is transmitted in the 

processing carried out at the step S135, the license server 4 
presents usage conditions at a step S153 of a flowchart shown 
in Fig. 11, as will be described later. Then, at the next step 
S136, the CPU 21 employed in the client 1 receives the 
presented usage conditions from the license server 4 and 
displays them on the output unit 27. The user operates the 
input unit 2 6 to select one of the displayed usage conditions 
and/or newly add a predetermined usage condition. Subsequently, 
at the next step S137, the CPU 21 transmits an application to 
purchase a usage condition selected as described above or a 
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condition to update a license to the license server 4. In 
response to the application, the license server 4 transmits an 
eventual usage condition at a step S154 of the flowchart shown 
in Fig. 11, as will be described later. Then, at the next step 
S138, the CPU 21 employed in the client 1 receives the 
eventual usage condition from the license server 4. 
Subsequently, at the next step S139, the received eventual 
usage condition is used as an update of the license's usage 
condition already stored in the storage unit 28. 
[0133] Fig. 11 is a flowchart used for explaining the 

processing carried out by the license server 4 to update a 
license in conjunction with the processing carried out by the 
client 1 to request that the license be updated. 
[0134] As shown in the figure, the flowchart begins with 

a step S151 at which the license server 4 is accessed by the 
client 1. Then, at the next step S152, the CPU 21 employed in 
the license server 4 receives a request to update a license 
from the client 1 along with the license-specifying 
information transmitted by the client 1 at the step S135. 
[0135] Subsequently, at the next step S153, the CPU 21 

reads out a usage condition for the license to be updated in 
accordance with the request to update the license, or reads 
out a condition for updating the license, from the storage 
unit 28. The CPU 21 then transmits the condition to the client 
1. 

[0136] In response to the transmitted condition, assume 

that the user of the client 1 enters an application to 
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purchase the usage condition in processing carried out at the 
step S137 of the flowchart shown in Fig. 10. In this case, at 
the next step S154, the CPU 21 employed in the license server 
4 generates data for the applied usage condition and transmits 
the data to the client 1. As described above, the client 1 
uses the received usage condition as an update of the already 
cataloged usage condition of the license. As described above, 
the usage condition was updated in the processing carried out 
at the step S139. 

[0137] In the present invention, keys of devices and keys 

of licenses are managed on the basis of the principle of a 
broadcast-encryption system as shown in Fig. 12. The keys are 
organized into a hierarchical tree structure. Leaves, which 
are at the bottom hierarchical layer, each correspond to keys 
of each device. In the typical structure shown in Fig. 12, 16 
keys 0 to 15 corresponding to 16 devices or 16 licenses are 
generated . 

[0138] Each key denoted by a circular mark is placed at a 

node of the tree structure. A root key KR is placed at a root 
node on the top of the tree structure. At the nodes on the 
second hierarchical layer, keys K0 and Kl are provided. At the 
nodes on the third hierarchical layer, keys K00 to Kll are 
placed. At the nodes on the fourth hierarchical layer, keys 
K000 to Kill are provided. The leaves at the nodes on the 
bottom hierarchical layer or device nodes are keys K0000 to 
Kllll. 

[0139] In the hierarchical tree structure, for example, 
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keys K0010 and K0011 are each a subordinate of key K001. In 
the same way, keys K000 and K001 are each a subordinate of key 
K00. By the same token, on the higher hierarchical layers, 
keys K00 and KOI are each a subordinate of key KO . Likewise, 
keys KO and Kl are each a subordinate of the root key KR. 
[0140] Keys required for using content comprise a leaf at 

a device node of the bottom hierarchical layer and keys at the 
nodes on higher hierarchical layers including the root key KR. 
The leaf and the keys on the higher hierarchical layers 
including the root key KR form a path. For example, keys 
required for using Content 3 are managed by each key of the 
path including keys K0011, K001, K00, KO and KR, which form a 
path starting with the leaf K0011 and ending with the root key 
KR on the basis of the license corresponding to the leaf ID. 

[0141] The content-exchanging system provided by the 

present invention typically adopts the principle shown in Fig. 
12 to manage keys of devices and licenses placed at nodes laid 
out to form an 8 + 24 + 32-layer structure shown in Fig. 13. 
In the structure shown in Fig. 13, there are eight subordinate 
hierarchical layers below the root node. A key at each node of 
the eight hierarchical layers is associated with a category. 
Examples of categories are a category of equipment using a 
semiconductor memory such as a Memory Stick (trademark) and a 
category of equipment for receiving digital broadcasts. 

[0142] One of the category nodes is the root node of a 

system called a T system provided by the present invention for 
managing licenses. 
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[0143] To put it in detail, subordinates of the root node 

of the T system are nodes on 24 hierarchical layers. A key at 
each of the subordinate nodes is associated with a license. 
Thus, it is possible to prescribe 2 24 licenses or about 16 mega 
or about 1.6 million licenses. Further subordinates on the 
lower side are 32 hierarchical layers, which allow 2 32 users 
(or clients 1) or about 4 giga or about 4 billion users (or 
clients 1) to be prescribed. Keys placed at nodes on the 32 
hierarchical layers are each a DNK (Device Node Key) . 
[0144] Keys for a device or keys for a license are placed 

along a path passing through nodes at the 64 (= 8 + 24 + 32) 
hierarchical layers. Thus, such a path is associated with a 
device or a license. More particularly, content keys used for 
encrypting content are encrypted by keys placed at nodes 
passed through by a path associated with a license for the 
content. A key at an upper hierarchical layer is encrypted by 
using its direct subordinate key on a hierarchical layer 
directly below and put in an EKB to be described later by 
referring to Fig. 15. A DNK on the bottom hierarchical layer 
is not put in the EKB, but included in service data to be 
granted to the client 1 of the user. The client 1 uses a DNK 
included in the license to decrypt a key, which is placed on a 
hierarchical layer directly above the DNK and included in the 
EKB shown in Fig. 15. The EKB is distributed along with the 
data of the content. The client 1 then uses the decrypted key 
to decrypt a key, which is placed on a hierarchical layer 
directly above the decrypted key and included in the EKB. This 
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decryption process is carried out repeatedly until the client 
1 is capable of obtaining all keys placed at nodes passed 
through by the path associated with the license. 
[0145] Fig. 14 is a diagram showing the typical 

classification of categories each associated with a key of a 
hierarchical tree structure. As shown in Fig. 14, on the top 
of the hierarchical tree structure, a root key KR2301 is set. 
On an intermediate hierarchical layer under the root key 
KR2301, a node key 2302 is set. On the bottom hierarchical 
layer, a leaf key 2303 is set. Each device has a leaf key, 
node keys and the root key. The nodes keys owned by the device 
are provided along a path which is associated with the device 
and connects the leaf key to the root key. 

[0146] A predetermined node on an Mth hierarchical layer 

from the root key is set as a category node 2304. In the 
example shown in Fig. 13, let M be 8 . Each node on the Mth 
hierarchical layer is used as a node for setting a root key 
for a device pertaining to a specific category. That is to say, 
a device of a category is associated with a path starting at a 
node on the Mth hierarchical layer, passing through nodes on 
(M + l)th and lower hierarchical layers, and ending at a leaf 
on the bottom hierarchical layer. 

[0147] Assume that, at a node 2305 on the Mth 

hierarchical layer of the hierarchical tree structure shown in 
Fig. 14, a category of a Memory Stick (trademark) is set. In 
this case, linked nodes and leaves below this node 2305 are 
used as nodes and leaves provided specially for the category 
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including a variety of devices each using the Memory Stick. 
That is to say, nodes and a leaf under the node 2305 are 
defined as a set of nodes and a leaf which are related to a 
device defined in the category of the Memory Stick. 
[0148] In addition, a node on a hierarchical layer 

several levels below the Mth hierarchical layer can be set as 
a subcategory node 2306. In the hierarchical tree structure 
shown in Fig. 14, a node on a hierarchical layer two levels 
below the Memory Stick category hierarchical layer, on which 
the node 2305 is provided, is set as a subcategory node, that 
is, a node for a subcategory included in the category of 
devices each using a Memory Stick. Furthermore, on a 
hierarchical layer under the node 2306 for a subcategory of 
playback-only equipment, a node 2307 for a telephone with a 
function to play back music is set. Such a telephone is 
included in the category of playback-only equipment. Moreover, 
on a hierarchical layer under the node 2307, a PHS node 2308 
and a cellular-phone node 2309 are provided. A PHS and a 
cellular phone are included in the category of a telephone 
with a function to play back music. 

[0149] In addition, categories and subcategories are 

provided not only for devices but also for nodes controlled by 
a manufacturer, content provider and a charging institution 
independently or any arbitrary units, which can be processing 
units, control units, presentation service units or the like. 
These units are each referred to as an entity, which is a 
generic technical term. Assume that a category node is set as 
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a root node provided specially for a game machine XYZ sold by 
a game machine manufacturer. In this case, the game machine 
manufacturer is capable of selling the game machine XYZ by 
storing node keys and a leaf key, which are provided on 
hierarchical layers below the root node, in the game machine 
XYZ . Then, encrypted contents or a variety of keys are 
distributed, or the keys are updated by generating an EKB. The 
EKB consists of node keys and a leaf key which are provided on 
hierarchical layers below the root node. In this way, it is 
possible to distribute data usable only by a device under the 
root node . 

[0150] As described above, a node is used as a root node 

and nodes on hierarchical layers below the root node are each 
set as a category-related node or a subcategory-related node. 
In this way, an institution such as a manufacturer or content 
provider, which manages a root node on a category hierarchical 
layer or a subcategory hierarchical layer, is capable of 
generating an EKB (Enabling Key Block) with a key at the root 
node used as the root key thereof by itself and distributing 
the EKB to devices pertaining to hierarchical layers below the 
root node. Thus, it is possible to update the keys of the EKB 
without no effects at all on devices pertaining to a category 
node not serving as a subordinate to the root node. 
[0151] Assume that, in the tree structure shown in Fig. 

12, four devices 0, 1, 2 and 3 pertaining to a group share 
common keys K00, K0 and KR as node keys. By using this node- 
key-sharing configuration, a common content key can be 
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provided only to devices 0, 1, 2 and 3. For example, node key 
K00 itself, which is shared by devices 0, 1, 2 and 3, is set 
as the common content key. In this way, it is possible to set 
content key common to devices 0, 1, 2 and 3 without 
transmitting a new key. As an alternative, a new content key 
Kcon is encrypted by using the node key K00 to result in an 
encrypted value Enc(K00, Kcon), which is then distributed to 
devices 0, 1, 2 and 3 by way of a network or by storing the 
value Enc(K00, Kcon) in a storage medium distributed to 
devices 0, 1, 2 and 3. In this way, only devices 0, 1, 2 and 3 
are capable of decrypting the value Enc(K00, Kcon) by using 
the common node key K00 shared by devices 0, 1, 2 and 3 to 
produce the content key Kcon. It should be noted that notation 
Enc(Ka, Kb) denotes data obtained as a result of encryption of 
a key Kb by using a key Ka . 

[0152] In addition, assume that it is discovered at a 

point time t that keys K0011, K001, K00, K0 and KR owned by 
device 3 have been analyzed and identified by a hacker. In 
this case, in order to protect data exchanged thereafter in a 
system (or a group of devices 0, 1, 2 and 3), device 3 needs 
to be detached from the system. In addition, node keys K001, 
K0 0, KO and KR need to be updated to respectively new keys 
K(t)001, K(t)00, K(t)0 and K(t)R to be transmitted to devices 
0, 1 and 2. It should be noted that notation K(t)aaa is an 
updated key of generation of time point t and is obtained by 
updating a key Kaaa. 

[0153] Processing to distribute an updated key is 
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explained below. For example, keys are updated as follows. In 
the case of the processing to update keys for devices 0, 1 and 
2 as described above, a table is supplied to devices 0, 1 and 
2 by way of a network or by storing the table in a storage 
unit and supplying the storage unit to devices 0, 1 and 2. The 
table is block data called an EKB (Enabling Key Block) shown 
in Fig. 15A. It should be noted that the EKB (Enabling Key 
Block) comprises encrypted keys for distributing newly updated 
keys to devices associated with leaves at the nodes on the 
bottom hierarchical layer of a tree structure like the one 
shown in Fig. 12. The EKB (Enabling Key Block) is also called 
a KRB (Key Renewal Block) . 

[0154] The EKB (Enabling Key Block) shown in Fig. 15A is 

structured as block data that can be updated only by a device 
requiring node keys thereof to be updated. The typical EKB 
shown in Fig. 15A is block data created with the objective of 
distributing updated node keys of generation of time point t 
to devices 0, 1 and 2 of the tree structure shown in Fig. 12. 
As is obvious from Fig. 12, devices 0 and 1 each require 
K(t)00, K(t)0 and K(t)R as updated node keys. On the other 
hand, device 2 requires K(t)001, K(t)00, K(t)0 and K(t)R as 
updated node keys . 

[0155] As shown in Fig. 15A, the EKB includes a plurality 

of encrypted keys. An encrypted key of the fifth row of the 
table from the top shown in Fig. 15A is Enc(K0010, K(t)001), 
which is an updated node key K(t)001 encrypted by using a leaf 
key K0010 owned by the device 2. The device 2 is thus capable 
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of obtaining the updated node key K(t)001 by decryption of the 
encrypted key Enc(K0010, K(t)OOl) by using the leaf key K0010 
owned by device 2 itself. In addition, by using the updated 
node key K(t)001 obtained as a result of the decryption, it is 
possible to decrypt an encrypted key Enc (K{t) 001, K(t)00) of 
the fourth row of the table shown in Fig. 15A to result in an 
updated node key K(t)00. 

[0156] Thereafter, in such a sequential decryption 

process, an encrypted key Enc(K(t)00, K(t)0) of the second row 
of the table shown in Fig. 15A is decrypted to result in the 
updated node key K(t)0, which is then used for decrypting an 
encrypted key Enc(K(t)0, K(t)R) of the first row to result in 
the updated node key K(t)R. 

[0157] On the other hand, a node key KOOO is not a key to 

be updated. Updated node keys required by devices 0 and 1 
associated with nodes 0 and 1 respectively are K(t)00, K(t)0 
and K(t)R. Devices 0 and 1 associated with nodes 0 and 1 
respectively each use device keys K0000 and K0001 to decrypt 
an encrypted key Enc (KOOO, K(t)00) of the third row of the 
table shown in Fig. 15A to obtain an updated node key K(t)00. 
Thereafter, in the sequential decryption process, an encrypted 
key Enc(K(t)00, K(t)0) of the second row of the table shown in 
Fig. 15A is decrypted to result in the updated node key K(t)0, 
which is then used for decrypting an encrypted key Enc(K(t)0, 
K(t)R) of the first row to result in the updated node key 
K(t)R. In this way, devices 0, 1 and 2 are each capable of 
obtaining the updated node key K(t)R. 
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[0158] It should be noted that indices shown in Fig. 15A 

are absolute addresses of node keys and leaf keys. The node 
keys and leaf keys are each used as a decryption key for 
decrypting an encrypted key on the right side of the figure. 
[0159] When it is not necessary to update a node key 

K(t)0 on an upper hierarchical layer of the tree structure 
shown in Fig. 12 and the root key K(t)R, while it is necessary 
to carry out processing to update only a node key K00, an 
updated node key K(t)00 can be distributed to devices 0, 1 and 
2 by using an EKB (Enabling Key Block) shown in Fig. 15B. 

i*i [0160] The EKB shown in Fig. 15B can be used for 

Q 

q distributing typically new content keys common to devxces 

•(%} pertaining to a specific group. Assume that devices 0, 1, 2 

and 3 pertaining to a group enclosed by a dotted line in Fig. 
12 each use a recording medium and require a new common 
™; content key K(t)con. In this case, data Enc(K(t)00, K(t)con) 

is distributed to devices 0, 1, 2 and 3 along with the EKB 
shown in Fig. 15B. The data Enc(K(t)00, K(t)con) is a result 
of encryption of the newly updated content key K(t)con common 
to devices 0, 1, 2 and 3. The newly updated content key 
K(t)con is encrypted by using K(t)00 which is a result of 
encryption of a node key K00 common to devices 0, 1, 2 and 3. 
By this, the encrypted data Enc(K(t)00, K(t)con) can be 
distributed so that equipment of other groups such as device 4 
cannot decrypt the encrypted data. 

[0161] That is to say, devices 0, 1 and 2 are each 

capable of decrypting encrypted data by using the key K(t)00 
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obtained as a result of EKB processing in order to obtain the 
content key K(t)con of generation of time point t. 
[0162] Fig. 16 is a diagram showing the typical 

processing carried out by device 0, which has received the 
data Enc(K(t)00, K(t)con) and the EKB shown in Fig. 15B 
through a recording medium, to obtain the content key K(t)con 
of generation of time point t. As described earlier, the data 
Enc(K(t)00, K(t)con) is a result of encryption of the newly 
updated content key K(t)con common to devices 0, 1, 2 and 3. 
That is to say, in this typical processing, encrypted message 
data distributed using the EKB is the content key K(t)con. 
[0163] As shown in Fig. 16, in the same EKB processing as 

that described above, device 0 generates a node key K(t)00 by 
using an EKB of generation of time point t and a node key K000 
stored in advance in the recording medium by itself. The EKB 
has been stored in the recording medium. Then, device 0 uses 
the updated node key K(t)00 obtained as a result of decryption 
to decrypt the updated content key K(t)con. Device 0 then 
encrypts it by using a leaf key KOO0 0 owned only by device 0 
for later use. 

[0164] Fig. 17 is a diagram showing a typical format of 

an EKB (Enabling Key Block) . A version 601 is an identifier 
indicating a version of the EKB (Enabling Key Block) . It 
should be noted that the version 601 has the functions of 
determining the most recent EKB and of indicating the relation 
with contents. A depth 602 is the number of hierarchical 
layers in a hierarchical-tree structure for a device serving 
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as a destination of the EKB (Enabling Key Block) . A data 
pointer 603 is a pointer pointing to a position in a data 
portion 606 of the EKB (Enabling Key Block) . A tag pointer 604 
is a pointer pointing to the position of a tag 607, and a 
signature pointer 605 is a pointer pointing to the position of 
a signature 608. 

[0165] The data portion 606 is typically encrypted 

updated node keys, that is, encrypted keys obtained as a 
result of encryption of updated node keys as shown in Fig. 16. 
[0166] The tag 607 is a tag showing the positional 

relationship between encrypted node keys and encrypted leaf 
keys. The encrypted node keys and the encrypted leaf keys are 
included in the data portion 606. A rule of providing a tag is 
explained by referring to Fig. 18. 

[0167] Fig. 18 is a diagram showing an example of 

transmitting an EKB (Enabling Key Block) explained earlier by 
referring to Fig. 15A. Data in this case is shown in Fig. 18B. 
The address of a top node included in an encrypted key at that 
time is referred to as a top-node address. In this example, 
since an updated root key K(t)R is included, the top-node 
address is KR. In this case, for example, data Enc(K(t)0, 
K(t)R) of the first row corresponds to a position P0 in a 
hierarchical tree structure shown in Fig. 18A. Data Enc(K(t)00, 
K(t)0) of the second row corresponds to a position POO on the 
lower left side of the position P0 in the hierarchical tree 
structure. If there is data on a hierarchical layer below a 
predetermined position of the hierarchical tree structure, the 
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tag is set at 0. If, on the other hand, there is no data on a 
hierarchical layer below a predetermined position of the 
hierarchical tree structure, the tag is set at 1. Tags are set 
in the following format: {Left (L) tag, Right (R) tag} 
explained below. At the position POO on the lower left side of 
the position P0 corresponding to the data Enc(K(t)0, K(t)R) of 
the first row shown in Fig. 18B, there is data. Thus, the L 
tag is set at 0 . At a position on the lower right side of the 
position P0, on the other hand, there is no data. In this case, 
the R tag is set at 1 . In this way, for each data, tags are 
set. Fig. 18C is a diagram showing a configuration including a 
typical array of pieces of data and an array of tags. 
[0168] A tag is set to indicate which position in the 

tree structure the corresponding data Enc(Kxxx, Kyyy) is 
located at. The key data Enc(Kxxx, Kyyy) and so on stored in 
the data portion 606 is no more than an array of keys, which 
have been encrypted in a simple way. With the tag described 
above, however, it is possible to identify the position of an 
encrypted key, which is stored as data, in the tree structure. 
Without the tag described above, it is also possible to 
construct data by using node indices associated with pieces of 
encrypted data as is the case with the configuration explained 
earlier by referring to Fig. 15. An example of the data 
construction is given as follows: 

0: Enc(K(t)0, K(t)R) 

00: Enc(K(t)00, K(t)0) 

000: Enc(K(t)000, K(t)00) 
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[0169] A configuration using such indices, however, 

results in redundant data and the amount of data thus 
increases. As a result, such a configuration is not desirable 
for distribution through a network or for other purposes. By 
using tags as index data showing the positions of keys, 
however, the positions of keys can be recognized by using only 
a small amount of data. 

[0170] The EKB format is further explained by referring 

back to Fig. 17. The signature 608 is an electronic signature 
of the institution issuing the EKB (Enabling Key Block) . 
Examples of such an institution are a key management center 
Q (the license server 4), content provider (the content server 

iU 3) and a charging institution (the charging server 5) . A 

□ device receiving the EKB confirms that the EKB is a valid EKB 

a 

■ s issued by an authorized EKB issuer by signature authentication, 

rlj [0171] It is possible to summarize processing to utilize 

content supplied by the content server 3 on the basis of a 

cm 

!%! license issued by the license server 4 as described above into 

what is shown in Fig. 19. 

[0172] As shown in the figure, when the content server 3 

provides content to the client 1, the license server 4 issues 
a license to the client 1. The content is Enc(Kc, Content), 
which is a notation indicating that the content has been 
encrypted by content key Kc . The content key Kc is encrypted 
by using a root key KR to produce Enc (KR, Kc) . The root key KR 
is obtained from the EKB and corresponds to the key K EKB c shown 
in Fig. 5. The content key Enc (KR, Kc) and the EKB are then 



added to the encrypted content. The content key Enc ( KR, Kc) , 
the EKB and the encrypted content are finally supplied to the 
client 1. 

[0173] As shown in Fig. 20, the EKB in the example shown 

in Fig. 19 typically includes Enc (DNK, KR) , which is a 
notation indicating that the root key KR has been encrypted by 
a DNK. Thus, by using a DNK included in service data, the 
client 1 is capable of obtaining the root key KR from the EKB. 
Then, it is possible to obtain the content key KC by 
decryption of Enc (KR, Kc) using the root key KR. Finally, it 
is possible to obtain the content by decryption of Enc(Kc, 
Content) using the content key Kc . 

[0174] By assigning a DNK to each client 1 in this way, 

it is also possible to individually revoke a client 1 in 
accordance with the principles shown in Figs. 12 and 15. 
[0175] In addition, by including an additional license 

leaf ID as a part of data in the distribution, service data is 
associated with a license so that it is possible to avoid an 
illegal copy operation in the client 1. 

[0176] Furthermore, by distributing a secret key and a 

certificate for each client as service data, it is possible to 
create content for which the secret key and the certificate 
for use by the client 1 are used to prevent the end user from 
carrying out an illegal operation to copy the content. The use 
of the secret key and the certificate will be described later 
by referring to the flowchart shown in Fig. 28. 

[0177] As described earlier by referring to Fig. 13, in 
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accordance with the present invention, a T system for managing 
licenses at a category node is associated with a category of 
devices each used for using contents. Thus, a plurality of 
DNKs can be owned by the same device. As a result, contents 
pertaining to different categories can be managed using one 
device . 

[0178] Fig. 21 is an explanatory diagram showing the 

assignment of plural contents to one device. To be more 
specific, a license for using content 1, to which DNK 1 is 
assigned, is recorded in a device Dl on the basis of the T 
system. By the same token, content 2, to which DNK 2 is 
assigned, can be recorded in the device Dl by transferring 
content 2 from a CD to a Memory Stick. In this way, the device 
Dl is capable of simultaneously handling two contents, namely, 
contents 1 and 2, which are distributed by different systems, 
namely, the T system and a device management system. This 
feature cannot be implemented in a case where only one DNK is 
assigned to a device. An example of such a case is a case in 
which an already assigned DNK is deleted when a new DNK is 
assigned . 

[0179] In addition, for example, license categories 1 and 

2 shown in Fig. 22 are assigned to each triangle of the 32 
lower-side hierarchical layers shown in Fig. 13. By such 
assignment, a category is classified into subcategories for 
managing smaller groups such as genres of the content, levels 
of the content, retail stores of the content and distribution 
services of the content. 
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[0180] In the typical assignment shown in Fig. 22, for 

instance, license categories 1 and 2 pertain to a jazz genre 
and a rock genre, respectively. License category 1 is 
associated with contents 1 and 2, each of which has a license 
ID of 1 and is distributed to users 1, 2 and 3. License 
category 2 includes contents 3, 4 and 5, each of which has a 
license ID of 2 and is distributed to users 1 and 3. 
[0181] As described above, in accordance with the present 

invention, independent key management can be executed for each 
category. 

[0182] In addition, instead of having a DNK embedded in 

equipment and/or media, a DNK can also be downloaded to- each 
equipment and/or each media in catalog processing carried out 
by the license server 4 so as to implement a system allowing a 
user to purchase the key. 

[0183] It is desirable to provide content that can be 

used in all applications by adopting any technique of using 
the content after creation of the content without regard to 
what technique is adopted. For example, it is desirable to 
provide content that can be used in domains with different 
content distribution services or different usage conditions. 
In order to provide such content, according to the present 
invention, the license server 4 functioning as an 
authenticating station distributes secret keys and 
certificates of disclosed keys for the secret keys to users 
(clients 1) as described above. Then, the users each use a 
secret key to create a signature to be put on the content in 
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order to assure the integrity of the content and, thus, to 
prevent the content from being falsified. 

[0184] Typical processing of the case described above is 

explained by referring to the flowchart shown in Fig. 23. To 
be more specific, the processing is a ripping process carried 
out by the user to record data played back from a CD in the 
storage unit 28. 

[0185] As shown in the figure, the flowchart begins with 

a step S171 at which the CPU 21 employed in the client 1 
receives input recorded data played back from a CD from the 
communication unit 29. Then, at the next step S172, the CPU 21 
forms a judgment as to whether the recorded data input at the 
step S171 includes a watermark embedded in the data of the 
content. The watermark comprises 3-bit CCI (Copy Control 
Information) and a 1-bit trigger. If a watermark is detected, 
the flow of the processing goes on to a step S173 at which the 
CPU 21 carries out a process to extract the watermark. If, on 
the other hand, no watermark is detected, the watermark- 
extracting process is skipped. 

[0186] Then, at the next step S174, the CPU 21 creates 

data of a header to be recorded for the content. The data of 
the header comprises content ID, a license ID, a URL 
representing an access target for acquiring a license and a 
watermark. 

[0187] Subsequently, at the next step S175, by using the 

secret key of the CPU 21 itself, the CPU 21 creates a digital 
signature based on the data of the header created in the 
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processing carried out at the step S174. The secret key has 
been obtained from the license server 4 at the step S67 of the 
flowchart shown in Fig. 7. 

[0188] Then, at the next step S176, the CPU 21 controls 

the encryption and decryption unit 2 4 to encrypt the content 
by using content key. The content key has been acquired at the 
same time as the content (See Fig. 5 or 9) . 

[0189] Subsequently, at the next step S177, CPU 21 

records the data onto a magneto-optical disk 43 in a file 
format. Typically, the magneto-optical disk 43 is a mini disc. 
[0190] It should be noted that, in the case of a mini 

disk used as the recording medium, the CPU 21 supplies the 
content to the codec unit 25 at the step S17 6. The codec unit 
25 encodes the content, typically in accordance with the 
ATRAC 3 system. The encoded content is further encrypted by the 
encryption and decryption unit 24. 

[0191] Fig. 24 is a diagram showing a model of content 

recorded on the recording medium. A watermark WM extracted 
from the encrypted content (E (At 3 ) ) is recorded in a header 
outside the content. 

[0192] Fig. 25 is a diagram showing a more detailed 

configuration of the file format in which the content is 
recorded onto the recording medium. As is obvious from the 
typical configuration, a header including content ID (CID) , a 
license ID (LID), a URL and a watermark (WM) is recorded. In 
addition, an EKB, data Enc ( KR, Kc) , a certificate (Cert), a 
digital header (Sig (Header) ) , data Enc(Kc, Content), meta data 
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and a mark are recorded. The data Enc(Kr, Kc) is a result of 
encryption of content key Kc by using a root key KR, whereas 
the data Enc(Kc, Content) is a result of encryption of the 
content by using the content key Kc . The digital header 
Sig (Header) has been generated on the basis of the header. 
[0193] The watermark is embedded in the content. As shown 

in Figs. 24 and 25, in addition to within the content, the 
watermark is also placed in the header so that information 
embedded in the content as the watermark can be detected fast 
and with ease. Thus, it is possible to quickly form a judgment 
as to whether the content can be copied. 

[0194] It should noted that the meta data typically 

represents a jacket, pictures, a libretto and other 
information. The mark will be described later by referring to 
Fig. 31. 

[0195] Fig. 26 is a diagram showing a typical disclosed- 

key certificate used as the certificate of a disclosed key. 
Normally, a disclosed-key certificate is a certificate issued 
by a CA (Certificate Authority) in a disclosed-key encryption 
system. A disclosed-key certificate is issued by the 
Certificate Authority by adding information such as a term of 
validity to a disclosed key and a user ID supplied to the 
Certificate Authority, as well as by putting a digital 
signature of the Certificate Authority thereon. In accordance 
with the present invention, the license server 4 or the 
content server 3 issues a certificate and a secret key and, 
thus, also a disclosed key. Therefore, by presenting 
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information such as a user ID and a password to the license 
server 4 to be cataloged therein, the user is able to obtain a 
disclosed- key certificate. 

[0196] The disclosed-key certificate shown in Fig. 26 

includes a message. The message includes a version number of 
the certificate, a serial number issued for the user of the 
certificate by the license server 4, an algorithm and 
parameters which are used for a digital signature, the name of 
the Certificate Authority, the term of validity of the 
certificate, an ID assigned to the user of the certificate and 
a disclosed key of the certificate user. In this case, the 
Certificate Authority is the license server 4. The ID assigned 
to the user is a node ID or a leaf ID. A digital signature 
created by the license server 4 serving as the Certificate 
Authority is added to the message. The digital signature is 
data created by using a secret key of the license server 4 on 
the basis of a hash value generated by application of a hash 
function to the message. 

[0197] In the case of the typical key organization shown 

in Fig. 12, for example, the node ID or the leaf ID is '0000' 
for device 0, '0001' for device 1 or '1111' for device 15. On 
the basis of such an ID, it is thus possible to determine at 
which position in the tree structure, that is, at which leaf 
or which node of the tree structure, a device (entity) 
identified by the ID is located. 

[0198] By distributing a license required to use content 

separately from the content in this way, the content can be 
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distributed with a higher degree of freedom. Content obtained 
by adopting an arbitrary method or obtained through an 
arbitrary route can thus be handled unitarily. 

[0199] In addition, by constructing a file format as 

shown in Fig. 25, it is needless to say that the copyright of 
the content with such a format can be managed when the content 
is distributed through the Internet or even when the content 
is presented to SDMI (Secure Digital Music Initiative) 
equipment . 

[0200] Furthermore, even if content is presented by 

recording the content in a recording medium or presented 
through the Internet 2 as shown in Fig. 27, for example, by 
carrying out the same processing, it is possible to check out 
the content typically for a predetermined PD (Portable Device) 
used as SDMI (Secure Digital Music Initiative) equipment. 
[0201] By referring to the flowchart shown in Fig. 28, 

the following description explains the processing to check out 
content for a client such as a PD other than the client 1. 
[0202] As shown in the figure, the flowchart begins with 

a step S191 at which the CPU 21 forms a judgment as to whether 
a digital signature has been put on the content. If the 
outcome of the judgment indicates that a digital signature has 
been put on the content, the flow of the processing goes on to 
a step S192 at which the CPU 21 extracts a disclosed-key 
certificate and carries out processing to authenticate the 
certificate by using the disclosed key of the license server 4 
serving as the Certificate Authority. More particularly, the 
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client 1 acquires a disclosed key for a secret key of the 
license server 4 from the license server 4, and uses the 
disclosed key to decrypt the digital signature put on the 
disclosed-key certificate. As described earlier by referring 
to Fig. 26, the digital signature is generated on the basis of 
the secret key of the license server 4 serving as the 
Certificate Authority, and can be decrypted by using the 
disclosed key of the license server 4. Furthermore, the CPU 21 
applies a hash function to the whole message of the 
certificate to generate a hash value. Then, the CPU 21 
compares the generated hash value with a hash value obtained 
as a result of decryption of the digital signature. If the 
generated hash value matches the hash value obtained as a 
result of decryption of the digital signature, the certificate 
is determined to be not a false certificate. If, on the other 
hand, the generated hash value does not match the hash value 
obtained as a result of decryption of the digital signature, 
this certificate is determined to be a false one. 
[0203] Thus, at the next step S193, the CPU 21 forms a 

judgment as to whether the certificate has been falsified. If 
the outcome of the judgment indicates that the certificate has 
not been falsified, the flow of the processing goes on to a 
step S194 at which the CPU 21 carries out processing to 
authenticate the certificate by using an EKB . The certificate 
is authenticated by examining whether the EKB can be traced on 
the basis of a leaf ID included in the certificate. For more 
information on the leaf ID, refer to Fig. 26. The 
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authentication is explained by referring to Figs. 29 and 30 as 
follows . 

[0204] As shown in Fig. 29, assume that a device owning a 

leaf key K1001 is a revoked device. In this case, an EKB 
having a tag and data (an encrypted key) like the one shown in 
Fig. 30 are distributed to devices each corresponding to a 
leaf. In order to revoke device '1001' shown in Fig. 29, this 
EKB is an EKB for updating keys KR, Kl, K10 and K100. 
[0205] All leaves other than a leaf corresponding to the 

revoked device '1001' are capable of acquiring the updated 
root key K(t)R. That is to say, since any of those leaves on a 
hierarchical layer below the node key K0 has the unupdated 
node key K0 inside the device, the leaf is capable of 
obtaining the updated root key K(t)R by decrypting the 
encrypted key Enc(K0, K(t)R) using the key KO . 

[0206] In addition, a leaf on a hierarchical layer under 

the node key Kll is capable of obtaining the updated node key 
K(t)l by decryption of Enc(Kll, K(t)l) using the unupdated 
node key Kll. Furthermore, the updated root key K(t)R can be 
obtained by decryption of Enc(K(t)l, K(t)R) using the updated 
node key K(t)l. By the same token, a leaf on a hierarchical 
layer under the node key K101 is also capable of obtaining the 
updated root key K(t)R. 

[0207] In addition, a device '1000' owning an unrevoked 

leaf key K1000 is capable of obtaining a node key K(t)100 by 
decryption of Enc(K1000, K(t)100) using its own leaf key K1000 
The device then uses the node key K(t)100 to decrypt node keys 
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on upper hierarchical layers sequentially, one key after 
another, to eventually obtain the updated root key K(t)R. 
[0208] On the other hand, since the revoked device '1001' 

is not capable of obtaining an updated node key K(t)100 on an 
upper hierarchical layer one level above its own leaf by 
carrying out the EKB processing, the device is incapable of 
obtaining the updated root key K(t)R. 

[0209] An authorized device, that is, the client 1, which 

was not revoked, receives an EKB with tags and data shown in 
Fig. 30 from the license server 4 and stores them therein. 
[0210] Thus, each client is capable of carrying out an 

□ 

EKB tracing process by using the tags. The EKB tracing process 
is a process to form a judgment as to whether the key 
distribution tree can be traced from the root key at the top. 
[0211] Assume that a leaf ID of '1001' assigned to a leaf 

'1001' shown in Fig. 29 is grasped as 4 bits, namely, '1', '0', 

yy '0' and '1'. The EKB tracing process is carried out to form a 

□ 

fy judgment as to whether the tree can be traced by examining 

bits starting with the most significant bit down through least 
significant bits sequentially, one bit after another. To be 
more specific, a '1' bit indicates that the tracing should go 
to the right side while a '0' bit indicates that the tracing 
should go to the left side. 

[0212] Since the most significant bit of the ID '1001' is 

'1', the tracing goes on from the root key KR shown in Fig. 2 9 
to the right side. The first tag of the EKB, that is, the tag 
having a number of 0, is 0 : {0, 0}, which indicates that data 



exists at both the branches. In this case, since the tracing 
is capable of going on to the right side, it is possible to 
reach the node key Kl . 

[0213] Next, the tracing goes on to a node on a 

hierarchical layer below the node key Kl . Since the second bit 
of the ID '1001' is '0', the tracing goes on to the left side. 
The tag with a number of 1 indicates whether data exists on a 
hierarchical layer below a node key K0 on the left side. A tag 
indicating whether data exists on a hierarchical layer below 
the node key Kl is a tag with a number of 2 . As shown in 
Fig. 30, the tag with a number of 2 is 2 : {0, 0}, which 
indicates that data exists at both the branches. Thus, the 
tracing goes on to the left side and is capable of reaching a 
node key K10 . 

[0214] Furthermore, since the third bit of the ID '1001' 

is 0, the tracing goes on to the left side. At that time, a 
tag indicating whether data exists on a hierarchical layer 
below the node key K10 is a tag with a number of 3. The tag 
with a number of 3 is 3 : {0, 0}, which indicates that data 
exists at both the branches. Thus, the tracing goes on to the 
left side and is capable of reaching a node key K100. 
[0215] Furthermore, since the least significant bit of 

the ID '1001' is 1, the tracing goes on to the right side. A 
tag with a number of 4 corresponds to the node key Kll. A tag 
indicating whether data exists on a hierarchical layer below 
the node key K100 is a tag with a number of 5. The tag with a 
number of 5 is 5 : {0, 1}, which indicates that no data exists 
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on the right side. As a result, since the node '1001' can not 
be reached, the device with the ID of '1001' is determined to 
be a device incapable of acquiring the updated root key by 
using the EKB, or a revoked device. 

[0216] On the other hand, for example, a device ID having 

a leaf key K1000 is '1000'. Thus, when the EKB tracing process 
based on tags in the EKB is carried out as described above, it 
is possible to reach the node '1000'. As a result, the device 
with the ID of '1000' is determined to be an authorized device. 
[0217] Refer back to Fig. 28. At the next step S195, the 

CPU 21 forms a judgment as to whether the certificate has been 
revoked on the basis of the result of the authentication 
processing carried out at the step S194. If the certificate 
has not been revoked, the flow of the processing goes on to a 
step S196 at which processing is carried out to authenticate 
the digital signature by using a disclosed key included in the 
certificate . 

[0218] That is to say, as shown in Fig. 26, the 

certificate includes a disclosed key of the certificate user 
(or the content author) . The disclosed key is used for 
authenticating a digital signature Sig (Header) shown in Fig. 
25. More particularly, the disclosed key is used for 
decrypting the digital signature Sig (Header) in order to 
produce a hash value. This hash value is compared with a hash 
value obtained by application of a hash function to a header 
shown in Fig. 25. If both the hash values match each other, 
the header is confirmed as a header which has not been 
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falsified. Otherwise, the header is determined to have been 
falsified. 

[0219] Then, at the next step S197, the CPU 21 forms a 

judgment as to whether the header has been falsified. If the 
header has not been falsified, the flow of the processing goes 
on to a step S198 at which the watermark is authenticated. 
Subsequently, at the next step S199, the CPU 21 forms a 
judgment as to whether a result of the authentication of the 
watermark indicates that a check-out is possible. If a check- 
out is possible, the flow of the processing goes on to a step 
S2 00 at which the CPU 21 carries out the check out. That is, 
the CPU 21 transfers the content to the client 1 serving as a 
check-out destination to be copied thereby. 

[0220] If, on the other hand, the outcome of the judgment 

formed at the step S191 indicates that the digital signature 
does not exist, the outcome of the judgment formed at the step 
S193 indicates that the certificate has been falsified, the 
outcome of the judgment formed at the step S195 indicates that 
the certificate cannot be authenticated by using the EKB, the 
outcome of the judgment formed at the step S197 indicates that 
the header has been falsified, or the outcome of the judgment 
formed at the step S199 indicates that the watermark includes 
a description inhibiting the check-out, the flow of the 
processing goes on to a step S201 at which an error-handling 
process is carried out. That is to say, in this case, the 
check-out is prohibited. 

[0221] As described above, a certificate and a secret key 
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are distributed from the license server 4 to the user. By 
adding a digital signature at the creation of content, the 
genuineness of the author of the content can be assured. As a 
result, illegal distribution of the content can be avoided. 
[0222] In addition, by detecting a watermark at the 

creation of the content and adding the watermark to the 
digital signature, falsification of the watermark can be 
avoided. Thus, the genuineness of the content can be assured. 
[0223] As a result, once created, the genuineness of the 

original content can be assured without regard to what format 
the content is distributed in. 

[0224] In addition, the content does not have usage 

conditions. Instead, usage conditions are added to a license 
for the content. Thus, by changing usage conditions included 
in the license, conditions for using the content are also 
modified as well. 

[0225] Next, a method of using a mark is explained. In 

accordance with the present invention, usage conditions are 
added not to content but to a license for the content as 
described above. However, usage circumstances may vary from 
content to content. In order to solve this problem, a mark is 
added to content in accordance with the present invention as 
shown in Fig. 25. 

[0226] Since a license is associated with a plurality of 

contents, it is difficult to describe usage circumstances of 
each content in only usage conditions included in the license. 
In order to solve this problem, by adding usage circumstances 
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to the content, it is possible to manage the individual 
contents while managing the license. 

[0227] As shown in Fig. 31, the mark typically includes 

an ID (leaf ID) assigned to the user, an ownership flag, a 
usage start time and a copy count. 

[0228] In addition, the mark also includes an additional 

digital signature created on the basis of a message such as 
the leaf ID, the ownership flag, the usage start time and the 
copy count. 

[0229] The ownership flag is added, for example, when the 

user buys a license which allows the content to be used only 
for a predetermined period of time, as it is, or when the 
usage period is changed to a permanent usage period. The usage 
start time is described when the use of the content is started 
within a predetermined period of time. Assume that the period 
to download the content is limited. In this case, if the 
content is downloaded within the limited period of time, the 
date and time at which the content is actually downloaded are 
recorded as the usage start time. In this way, legal use of 
the content within a period of time is proven. 

[0230] Recorded as a log, the copy count is the number of 

operations carried out so far to copy the contents. 
[0231] By referring to the flowchart shown in Fig. 32, 

the following description explains processing carried out to 
add a mark to content when the user purchases a license. 
[0232] As shown in the figure, the flowchart begins with 

a step S221 at which the CPU 21 accesses the license server 4 
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through the Internet 2 in accordance with a command entered by 
the user via the input unit 26. 

[0233] Then, at the next step S222, the CPU 21 retrieves 

an input entered by the user through the input unit 2 6 and 
transmits to the license server 4 a request to purchase a 
license according to the input. 

[0234] In response to this request, the license server 4 

presents a price to purchase the license at a step S242 of the 
flowchart shown in Fig. 33 as will be described later. 
Subsequently, at the next step S223, the CPU 21 employed in 

h* the client 1 receives the price transmitted by the license 

Q 

Q server 4, and displays the price on the output unit 27. 

"~~4 

iiy [0235] On the basis of the displayed price, the user 

forms a judgment as to whether to agree or disagree on the 
is price. The user enters the outcome of the judgment to the 

ilj input unit 26. 

g [0236] Then, at the next step S224, on the basis of the 

:=j judgment outcome entered to the input unit 26, the CPU 21 

forms a judgment as to whether the price has been agreed on. 
If the price has been agreed on, the flow of the processing 
goes on to a step S225 at which the CPU 21 carries out 
processing to notify the license server 4 that the price has 
been agreed on. 

[0237] Receiving this notification, the license server 4 

transmits information representing a license purchase at the 
price, that is, a mark including a described ownership flag at 
a step S244 of the flowchart shown in Fig. 33. Subsequently, 



at the next step S226, the CPU 21 employed in the client 1 
receives the mark transmitted by the license server 4. Then, 
at the next step S227, the CPU 21 carries out processing to 
embed the mark in the content. Thus, the mark, including a 
described ownership flag as shown in Fig. 31, is recorded in 
the content associated with the purchased license as a mark 
for the content. In addition, since the message is updated at 
that time, the CPU 21 also updates the digital signature shown 
in Fig. 25 and stores the updated digital signature in the 
recording medium. 

[0238] If, on the other hand, the outcome of the judgment 

formed at the step S224 indicates that the price presented by 
the license server 4 has not been agreed on, the flow of the 
processing goes on to a step S228 at which the CPU 21 notifies 
the license server 4 that the price has not been agreed on. 
[0239] For the processing carried out by the client 1 as 

described above, the license server 4 performs processing 
represented by the flowchart shown in Fig. 33. 

[0240] As shown in the figure, the flowchart begins with 

a step S241 at which the CPU 21 employed in the license server 
4 receives a request for the purchase of a license from the 
client 1. As described above, such a request is transmitted by 
the client 1 at the step S222 of the flowchart shown in Fig. 
32. Then, at the next step S242, the CPU 21 reads out the 
price of the license to be purchased by the user from the 
storage unit 28, and transmits the price to the client 1. 
[0241] As described above, in response to the disclosed 
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price, the client 1 transmits the outcome of the judgment as 
to whether the price is agreed or disagreed on. 

[0242] Subsequently, at the next step S243, the CPU 21 

employed in the license server 4 determines whether the price 
is agreed on by the client 1 on the basis of the judgment 
outcome received from the client 1. If the price is agreed on, 
the flow of the processing goes on to a step S244 to generate 
a mark including a message representing the purchase of a 
license for the content, put a digital signature on the mark 
by using a secret key of its own and transmit the mark to the 
client 1. As described above, the mark transmitted in this way 
is recorded on the content in the storage unit 2 8 employed in 
the client 1 at the step S227 of Fig. 32. 

[0243] If, on the other hand, the CPU 21 employed in the 

license server 4 determines that the price is not agreed on by 
the client 1 at the step S243, the processing of the step S244 
is skipped. That is to say, in this case, the processing to 
purchase a license is not concluded. Thus, no mark is 
transmitted to the client 1. 

[0244] Fig. 34 is a diagram showing a typical 

configuration of the mark transmitted from the license server 
4 to the client 1 at the step S244. In this typical 
configuration, the mark comprises the leaf ID of the user, an 
ownership flag (Own) and a digital signature Sig s (Leaf ID, Own), 
which is generated from the leaf ID and the ownership flag on 
the basis of a secret key S of the license server 4. 
[0245] It should be noted that the mark is valid only for 
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specific content issued to a specific user. Thus, if the 
specific content is copied, the mark in the copied content is 
invalid. In this way, even if content is separated from a 
license and usage conditions are associated with the license, 
it is possible to render services according to usage 
circumstances for individual contents. 

[0246] Next, grouping is explained. A plurality of 

apparatuses and mediums are collected in a group in which 
content can be exchanged with a high degree of freedom. The 
formation of such a group is referred to as grouping. Normally, 
grouping forms a group comprising apparatuses and mediums 
which are owned by an individual. Conventionally, grouping 
also includes an operation to set a group key for each group. 
By associating a plurality of apparatuses and mediums 
collected in a group with a common license, however, grouping 
can be done with ease. 

[0247] In addition, grouping can be carried out by 

cataloging the apparatuses in advance. This kind of grouping 
is explained as follows. 

[0248] In this case, the user needs to catalog 

certificates of apparatuses to be grouped in a server in 
advance. The processing to catalog such certificates is 
explained by referring to the flowcharts shown in Figs. 35 and 
36. 

[0249] First of all, the processing to catalog the 

certificate of a client, that is, an apparatus to be grouped, 
is explained by referring to the flowchart shown in Fig. 35. 
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As shown in the figure, the flowchart begins with a step S2 61 
at which the CPU 21 employed in the client 1 creates its own 
certificate as a certificate of an apparatus to be grouped. 
This certificate includes its own disclosed key. 
[0250] Then, at the next step S262, the CPU 21 accesses 

the content server 3 based on an input entered by the user to 
the input unit 26. Subsequently, at the next step S2 63, the 
certificate created at the step S2 61 is transmitted to the 
content server 3 . 

[0251] It should be noted that a certificate received 

from the license server 4 can also be used without change as 
the certificate described above. 

[0252] The processing described above is carried out by 

all apparatuses to be grouped. 

[0253] By referring to the flowchart shown in Fig. 36, 

the following description explains the processing carried out 
by the content server 3 to catalog the certificate created by 
the client 1 in the process represented by the flowchart shown 
in Fig. 35. 

[0254] As shown in the figure, the flowchart begins with 

a step S271 at which the CPU 21 employed in the content server 
3 receives a certificate from the client 1. Then, at the next 
step S272, the certificate is cataloged in the storage unit 28 

[0255] The processing described above is carried out for 

each apparatus to be grouped. As a result, certificates of 
devices composing each group are cataloged in the storage unit 
28 employed in the content server 3, as shown in Fig. 37. 
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[0256] In the example shown in Fig. 37, certificates Cll 

to C14 are cataloged as certificates of group 1. These 
certificates Cll to C14 include corresponding disclosed keys 
Kpu to Kpi4, respectively. 

[0257] By the same token, certificates C21 to C23 are 

cataloged as certificates of group 2. These certificates C21 
to C23 include corresponding disclosed keys K P2 i to K P2 3, 
respectively . 

[0258] With a certificate cataloged for each apparatus 

composing such a group, the content server 3 carries out the 
processing represented by the flowchart shown in Fig. 38 when 
the user of an apparatus pertaining to a group makes a request 
for the presentation of content. 

[0259] As shown in the figure, the flowchart begins with 

a step S281 at which the CPU 21 employed in the content server 
3 carries out processing to authenticate the group's 
certificate selected from among the ones cataloged in the 
storage unit 28. 

[0260] As explained earlier by referring to Figs. 29 and 

30, in this authentication processing, an EKB is traced by 
using tags on the basis of the apparatus' leaf ID included in 
the certificate. The EKB has been distributed by the license 
server 4 to the content server 3. The authentication 
processing eliminates a revoked certificate. 

[0261] Then, at the next step S282, the CPU 21 employed 

in the content server 3 selects a certificate determined to be 
valid as a result of the authentication processing carried out 
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at the step S281. Subsequently, at the next step S283, the CPU 
21 encrypts a content key using a disclosed key of the 
apparatus' certificate selected in the processing carried out 
at the step S282 . Then, at the next step S284, the CPU 21 
transmits the content key encrypted in the processing carried 
out at the step S283 along with its content to the apparatus 
in the group making the request for the presentation of the 
content . 

[0262] Assume that the certificate C14 of one of the 

groups shown in Fig. 37 has been revoked. In this case, in the 
processing carried out at the step S283, encrypted data shown 
in Fig. 39 is typically generated. In the encrypted data shown 
in Fig. 39, content key Kc has been encrypted by using a 
disclosed key K P n of the certificate Cll, a disclosed key K P i 2 
of the certificate C12 or a disclosed key K P i 3 of the 
certificate C13. 

[0263] When receiving the content from the license server 

3 as a result of the processing represented by the flowchart 
shown in Fig. 38, the apparatus or the client pertaining to 
the group carries out processing represented by a flowchart 
shown in Fig. 40. 

[0264] As shown in Fig. 40, the flowchart begins with a 

step S291 at which the CPU 21 employed in the client 1 
receives the content key Kc and the content which are 
transmitted by the content server 3 in the processing carried 
out at the step S284 of the flowchart shown in Fig. 38. The 
content has been encrypted by using the content key Kc, which 
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has been encrypted by using a disclosed key held by the 
apparatus as described above. (Refer to Fig. 39). 

[0265] Then, at the next step S292, the CPU 21 decrypts 

the content key Kc, which has been received in the processing 
carried out at the step S291 and is destined for the client 1, 
using a secret key owned by the client 1. The CPU 21 then uses 
the decrypted content key to decrypt the content. 

[0266] For instance, take the apparatus corresponding to 

the certificate Cll shown in Fig. 39 as an example. The 
apparatus decrypts the content key Kc by using its own secret 
key corresponding to the disclosed key K P n. The apparatus then 
uses the decrypted content key Kc to decrypt the content. 

[0267] The same processing is carried out for apparatuses 

associated with the certificates C12 and C13. An apparatus 
associated with the revoked certificate C14 does not receive 
the content key Kc encrypted by its disclosed key attached to 
the content. Thus, the apparatus is not capable of decrypting 
the content key Kc by using its own secret key and thus is 
incapable of decrypting the content by using the decrypted 
content key Kc . 

[0268] As described above, apparatuses are grouped with 

respect to content keys, that is, contents. However, 
apparatuses may be grouped with respect to license keys, that 
is, licenses. 

[0269] As described above, apparatuses can be grouped 

without using special group keys or ICVs (Integrity Check 
Values) to be described later. This kind of grouping is 
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suitable for a group with a small scale. 

[0270] In accordance with the present invention, a 

license can be checked out, checked in, moved and copied. 
However, these operations must be based on rules determined by 
the SDMI. 

[0271] By referring to the flowcharts shown in Figs. 41 

and 42, the following description explains processing to check 
out a license using such a client. 

[0272] The description begins with an explanation of the 

processing carried out by a client to check out a license to 
another client with reference to the flowchart shown in Fig. 
41. As shown in the figure, the flowchart begins with a step 
S301 at which the CPU 21 employed in the client 1 reads out 
the number of check-out operations (Nl) which have been 
conducted for the license. The number of check-out operations 

(Nl) is included in usage conditions shown in Fig. 8. Thus, 
the number of check-out operations (Nl) is read out from the 
usage conditions . 

[0273] Then, at the next step S302, the CPU 21 employed 

in the client 1 reads out the maximum number of check-out 
operations (N2) permissible for the license. Also in this case, 
the maximum permissible number of check-out operations (N2) is 
read out from the usage conditions. 

[0274] Subsequently, at the next step S303, the CPU 21 

compares the number of check-out operations (Nl) read out at 
the step S301 with the maximum permissible number of check-out 
operations (N2) read out at the step S302 to form a judgment 
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as to whether the number of check-out operations (Nl) is 
greater or smaller than the maximum permissible number of 
check-out operations (N2) . 

[0275] If the number of check-out operations (Nl) is 

found to be smaller than the maximum permissible number of 
check-out operations (N2), the flow of the processing goes on 
to a step S304 at which the CPU 21 acquires the leaf key of a 
partner apparatus from the partner apparatus, which is a 
client serving as a check-out destination. The acquired leaf 
key is cataloged on a check-out list stored in the storage 
unit 28, being associated with a license ID serving as a 
check-out object. 

[0276] Then, at the next step S305, the CPU 21 increments 

the number of check-out operations (Nl) read out at the step 
S301 by 1. Subsequently, at the next step S306, the CPU 21 
finds an ICV based on the message of the license. The ICV will 
be described later by referring to Figs. 4 6 to 50. By using 
the ICV, it is possible to prevent the license from being 
falsified. 

[0277] Then, at the next step S307, the CPU 21 encrypts 

the license serving as the check-out object and the ICV found 
at the step S306 using the disclosed key owned by the client 1 
itself. The encrypted license and the encrypted ICV are 
transmitted to the partner apparatus to be copied thereby 
along with an EKB and a certificate. Subsequently, at the next 
step S308, the CPU 21 catalogs the ICV found at the step S306 
on the check-out list stored in the storage unit 28 by 
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associating the ICV with the license ID and the leaf key of 
the partner apparatus. 

[0278] If, on the other hand, the outcome of the judgment 

formed at the step S303 indicates that the number of check-out 
operations (Nl) is not smaller than (for example, equal to) 
the maximum permissible number of check-out operations (N2), 
the flow of the processing goes on to a step S309 at which the 
CPU 21 carries out an error-handling process. This is because, 
since the number of check-out operations (Nl) is not smaller 
than the maximum permissible number of check-out operations 
(N2), indicating that the license has been checked out as many 
□ times as the number of allowable check-out operations (N2), 

|1| the license can no longer be checked out. Thus, in this case, 

O the license is not checked out. 

i 

[0279] By referring to the flowchart shown in Fig. 42, 

the following description explains the processing carried out 

iJ3 b Y a client receiving a license checked out in the check-out 

C 

Si processing represented by the flowchart shown in Fig. 41. 

[0280] The flowchart shown in Fig. 42 begins with a step 

S321 at which the CPU 21 employed in the client transmits the 
leaf key owned by the client itself to the partner apparatus, 
that is, the client 1 checking out the license. The leaf key 
is stored in the partner apparatus at the step S304, being 
associated with a license ID. 

[0281] Then, at the next step S322, the CPU 21 receives 

an encrypted license and an encrypted ICV along with an EKB 
and a certificate from the partner client 1. As described 
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earlier, the partner client 1 transmits the encrypted license 
and the encrypted ICV along with the EKB and the certificate 
at the step S307 of the flowchart shown in Fig. 41. 
[0282] Subsequently, at the next step S323, the CPU 21 

stores the encrypted license, the encrypted ICV, the EKB and 
the certificate, which were received at the step S322, in the 
storage unit 28. 

[0283] The client 1 receiving a checked-out license as 

described above uses the checked-out license to play back 
content in accordance with the processing represented by the 
flowchart shown in Fig. 43. 

[0284] As shown in the figure, the flowchart begins with 

a step S341 at which the CPU 21 employed in the client 1 finds 
an ICV of content specified by a command entered by the user 
to the input unit 2 6 as content to be played back. 
Subsequently, at the next step S342, the CPU 21 decrypts an 
encrypted ICV stored in the storage unit 28 using a disclosed 
key included in the certificate. 

[0285] Then, at the next step S343, the CPU 21 forms a 

judgment as to whether the ICV found at the step S341 matches 
the ICV read out and decrypted in the processing carried out 
at the step S342. The former matching the latter indicates 
that the license has not been falsified. In this case, the 
flow of the processing goes on to a step S344 at which the CPU 
21 carries out processing to play back the content. 
[0286] If, on the other hand, the outcome of the judgment 

formed at the step S343 indicates that the two ICVs do not 
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match each other, it is feared that the license has been 
falsified. In this case, the flow of the processing goes on to 
a step S345 at which the CPU 21 carries out an error-handling 
process. That is to say, the content cannot be played back by 
using this license. 

[0287] By referring to the flowchart shown in Fig. 44, 

the following description explains the processing carried out 
by a client to check in a license which was once checked out 
to another client 1 as described above. 

[0288] As shown in the figure, the flowchart begins with 

a step S361 at which the CPU 21 employed in the client 
receives the leaf key of a partner apparatus and the ID of a 
license to be checked in. The partner apparatus is a client 1 
which returns or checks in a license. Then, at the next step 
S3 62, the CPU 21 forms a judgment as to whether the license to 
be checked in, which is obtained at the step S361, is a 
license checked out by the client itself to the partner 
apparatus. This judgment is based on the ICV, the leaf key and 
the license ID which were stored in the storage unit 28 in the 
processing carried out at the step S308 of the flowchart shown 
in Fig. 41. That is to say, the CPU 21 determines whether the 
ICV, the leaf key and the license ID, which were received at 
the step S361, have been cataloged on the check-out list 
stored in the storage unit 28. If they have been cataloged on 
the check-out list, the CPU 21 determines that the license to 
be checked in is a license checked out by the client itself to 
the partner apparatus. 
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[0289] If the license to be checked in is a license 

checked out by the client itself to the partner apparatus, the 
flow of the processing goes on to a step S363 at which the CPU 
21 makes a request for deletion of the EKB, the certificate 
and the license of the partner apparatus. As will be described 
later, the partner apparatus deletes the license, the EKB and 
the certificate at a step S38 3 of the flowchart shown in Fig. 
45 in accordance with the request. 

[0290] Then, at the next step S364, since a check-out 

license is checked in, the CPU 21 decrements the number of 
check-out operations (Nl) by 1. 

[0291] Subsequently, at the next step S365, the CPU 21 

forms a judgment as to whether another license has been 
checked out to the partner apparatus. If there is no other 
license checked out to the partner apparatus, the flow of the 
processing goes on to a step S366 at which the CPU 21 deletes 
the partner apparatus from the check-out list for cataloging 
the partner apparatus as a check-in partner apparatus. If, on 
the other hand, the outcome of the judgment formed at the step 
S365 indicates that there is another license checked out to 
the partner apparatus, the processing of the step S366 is 
skipped. This is because it is quite within the bound of 
possibility that the other license is checked in by the 
partner apparatus . 

[0292] If the outcome of the judgment formed at the step 

S362 indicates that the license to be checked in is not a 
license checked out by the client itself to the partner 
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apparatus, the flow of the processing goes on to a step S367 
at which the CPU 21 carries out an error-handling process. 
That is to say, in this case, the check-in processing is not 
carried out since the license is not a license managed by the 
client itself. 

[0293] In an attempt made by the user to illegally copy 

the license, the check-in processing cannot be carried out 
since the stored ICV is not equal to the ICV found on the 
basis of the license acquired in the processing carried out at 
the step S361. 

[0294] Fig. 45 is a flowchart representing the processing 

carried out by a client 1 issuing a request to check in a 
license to another client carrying out the license-check-in 
processing represented by the flowchart shown in Fig. 44. 
[0295] The flowchart shown in Fig. 45 begins with a step 

S381 at which the CPU 21 employed in the client 1 transmits a 
leaf key and the ID of the license to be checked in to a 
partner apparatus, which is the client carrying out the 
license-check-in processing represented by the flowchart shown 
in Fig. 44. As described above, the partner apparatus receives 
the leaf key and the license ID at the step S361 and carries 
out processing to authenticate the license to be checked in on 
the basis of the leaf key and the license ID at the step S362. 
[0296] Then, at the next step S382, the CPU 21 employed 

in the client 1 forms a judgment as to whether a request for 
deletion of the license has been received from the partner 
apparatus. As described earlier, if the license is a proper 
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license to be checked in, the partner apparatus makes a 
request for deletion of the license, the EKB and the 
certificate in the processing carried out at the step S363. If 
the outcome of the judgment formed at the step S382 indicates 
that such a request has been received, the flow of the 
processing goes on to a step S383 at which the CPU 21 deletes 
the license, the EKB and the certificate. That is to say, the 
client 1 thus becomes no longer capable of using the license. 
Since the number of check-out operations (Nl) is decremented 
by 1 by the partner apparatus in the processing carried out at 
the step S364 of the flowchart shown in Fig. 44, the check-in 
processing is ended. 

[0297] If, on the other hand, the outcome of the judgment 

formed at the step S382 indicates that such a request was not 
received, the flow of the processing goes on to a step S384 at 
which the CPU 21 carries out an error-handling process. That 
is to say, in this case, the check-in processing cannot be 
carried out due to some reasons such as a discrepancy in ICV. 

[0298] The check-out processing and the check-in 

processing have been explained so far. Processing to copy or 
move a license can also be carried out as well. 

[0299] The following description explains the processing 

to generate an ICV (Integrity Check Value) of a license, 
associate the ICV with the license and form a judgment as to 
whether the license has been falsified by computation of an 
ICV in order to prevent the license from being falsified. It 
should be noted that the same processing can be applied to 
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content . 

[0300] An ICV (Integrity Check Value) of a license 

typically is computed by application of a hash function to the 
license as follows: 

i. ICV = hash (Kiev, LI, L2, ...) 
where notation Kiev denotes an ICV generation key whereas 
symbols LI and L2 each denote information on the license. A 
MAC (Message Authentication Code) of important information of 
the license is used as the information represented by LI and 
L2. 

[0301] Fig. 46 is a diagram showing the typical 

generation of a MAC value by using a DES encryption processing 
configuration. As is obvious from the configuration shown in 
Fig. 46, a processed message is divided into 8-byte units. In 
the following description, the divided message is referred to 
as Ml, M2, ... and MN . First of all, an initial value IV and Ml 
are supplied to a processing unit 24-1A for carrying out 
exclusive logical sum processing to result in an exclusive 
logical sum 11. Then, the exclusive logical sum 11 is supplied 
to a DES encryption unit 24-lB for encrypting sum 11 by using 
a key Kl to produce an encryption result El. Subsequently, El 
and M2 are supplied to a processing unit 24-2A for carrying 
out exclusive logical sum processing to result in an exclusive 
logical sum 12. Then, the exclusive logical sum 12 is supplied 
to a DES encryption unit 24-2B for encrypting sum 12 by using 
key Kl to produce an encryption result E2 . Thereafter, these 
operations are carried out repeatedly to encrypt all the 
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messages. Eventually, a result EN generated by a DES 
encryption unit 24-NB is a MAC (Message Authentication Code) . 

[0302] A hash function is then applied to such a license 

MAC value and an ICV generation key to generate an ICV 

(Integrity Check Value) . For example, an ICV computed at the 
generation of a license is compared with an ICV newly 
calculated from a license. If the ICVs match each other, the 
license is assured not to have been falsified. If the ICVs do 
not match each other, on the other hand, the license is 
determined to have been falsified. 

[0303] The following description explains a configuration 

to use an EKB (Enabling Key Block) for transmitting a key Kiev 
for generating the ICV (Integrity Check Value) of a license. 
In the configuration, message data encrypted using the EKB is 
used as the key Kiev for generating the ICV (Integrity Check 
Value) of a license. 

[0304] More particularly, Figs. 47 and 48 are each a 

diagram showing a typical configuration of using an EKB 
(Enabling Key Block) to distribute a key Kiev for generating 
the ICV (Integrity Check Value) of a common license for 
forming a judgment as to whether the license has been 
falsified when transmitting the license to a plurality of 
devices. To be more specific, Fig. 47 is a diagram showing the 
typical distribution of a decryptable key Kiev for generating 
the ICV (Integrity Check Value) of a license to devices 0, 1, 
2 and 3. On the other hand, Fig. 48 is a diagram showing the 
typical distribution of a decryptable key Kiev for generating 
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the ICV (Integrity Check Value) of a license to devices 0, 1, 
and 2 only, but not to device 3 which has been revoked. 
[0305] In the typical distribution shown in Fig. 47, an 

encrypted EKB (Enabling Key Block) , which can be decrypted, is 
generated. The EKB is used for transmitting data Enc(K(t)00, 
Kiev) and an updated node key K(t)00 to devices 0, 1, 2 and 3. 
The data Enc(K(t)00, Kiev) is a result of encrypting the 
check-value generation key Kiev using the updated node key 
K(t)00. The node key K(t)00 has been updated by using a node 
key and a leaf key which are owned by each of devices 0, 1, 2 
and 3. As shown on the right side of Fig. 47, first of all, 
each of devices 0, 1, 2 and 3 decrypts the EKB to obtain the 
updated node key K(t)00. Then, the updated node key K(t)00 is 
used for decrypting the encrypted check-value generation key 
Enc(K(t)00, Kiev) to obtain the check-value generation key 
Kiev. 

[0306] Other devices 4, 5, 6, 7 and so on are each 

incapable of obtaining the updated node key K(t)00 by 
processing an EKB (Enabling Key Block) and by using a node key 
and a leaf key which are owned by each of devices, even if the 
EKB is received by the devices. Thus, the check-value 
generation key can be transmitted to only authorized devices 
with a high degree of safety. 

[0307] Fig. 48 is a diagram showing a case in which 

device 3 pertaining to a group enclosed by a dotted line in 
Fig. 12 has been revoked because, for example, a key has 
leaked out, so that an EKB (Enabling Key Block) is generated 
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and distributed to only other members of the group, namely, 
devices 0, 1 and 2. The EKB (Enabling Key Block) can be 
decrypted only by the devices 0, 1 and 2. The EKB (Enabling 
Key Block) shown in Fig. 48 and data Enc(K(t)00, Kiev) are 
distributed. As described earlier, the data Enc(K(t)00, Kiev) 
is a result of encryption of a check-value generation key Kiev 
by using a node key K(t)00. 

[0308] On the right side of Fig. 48, a decryption 

procedure is shown. As shown in the figure, first of all, 
devices 0, 1 and 2 each acquire the updated node key K(t)00 by 
carrying out processing to decrypt the received EKB (Enabling 
Key Block) by using a leaf key or a node key owned by itself. 
Then, the check-value generation key Kiev is obtained by 
decryption based on the updated node key K(t)00. 

[0309] Other devices 4, 5, 6 and so on of the group shown 

in Fig. 12 are each incapable of acquiring the updated node 
key K(t)00 by using their own leaf key and node key even if 
the same EKB (Enabling Key Block) is distributed to those 
other devices. By the same token, revoked device 3 is also 
incapable of acquiring the updated node key K(t)00 by using 
its own leaf key and node key even if the same EKB (Enabling 
Key Block) is distributed to this device. Thus, only an 
authorized device is capable of decrypting and using the 
check-value generation key Kiev. 

[0310] In this way, by utilizing distribution of the 

check-value generation key Kiev through the use of an EKB, the 
amount of distributed data can be reduced and it is possible 
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to safely distribute the check-value generation key Kiev to 
only authorized parties capable of decrypting the check-value 
generation key Kiev. 

[0311] By using such an ICV (Integrity Check Value) of a 

license, it is possible to avoid illegal copies of the EKB and 
the encrypted license. Assume that media 1 is used for storing 
licenses Ll and L2 along with an EKB (Enabling Key Block) that 
can be used for acquiring their license keys, as shown in 
Fig. 49A. Let what is stored in media 1 be copied to media 2. 
In this case, the EKB and the licenses can be copied. A device 
capable of decrypting the EKB will also be capable of using 
the licenses. 

[0312] In the configuration shown in Fig. 49B, an 

integrity check value ICV(L1, L2 ) is stored in each media, 
being associated with licenses also stored therein. It should 
be noted that ICV(L1, L2) is an integrity check value of 
licenses Ll and L2 and is computed by applying a hash function 
to licenses Ll and L2 as follows: 

ii. ICV = hash (Kiev, Ll, L2) 
[0313] In the configuration shown in Fig. 49B, 

information stored in media 1 includes licenses 1 and 2 as 
well as the integrity check value ICV(L1, L2), which is 
computed by applying a hash function to licenses Ll and L2 . On 
the other hand, information stored in media 2 includes license 
Ll and an integrity check value ICV(Ll), which is computed by 
applying a hash function to license Ll . 

[0314] In this configuration, assume that (EKB, license 
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2) is copied from media 1 to media 2. In this case, a new 
license check value ICV(Ll, L2) can be generated in media 2. 
The new license check value ICV(L1, L2 ) is different from 
Kiev (LI) stored in media 2. It is thus obvious that the new 
license check value ICV(L1, L2 ) can be used to store a new 
license in media 2 by falsification or an illegal copy 
operation. In a device for playing back information stored in 
media 2, however, generated and stored ICVs can be checked at 
a step prior to the playback step to form a judgment as to 
whether the ICVs match each other. If the generated ICV is 
determined to not match the stored ICV, no playback operation 
is carried out. In this way, in this configuration, it is 
possible to prevent the license obtained by falsification or 
by carrying out an illegal copy operation from being played 
back. 

[0315] In addition, in order to further enhance the 

degree of safety, it is possible to devise a configuration in 
which the ICV (Integrity Check Value) of a license is 
generated on the basis of data including the value of a 
writable counter. More particularly, in the configuration, the 
ICV (Integrity Check Value) of a license is computed as 
follows : 

iii. ICV = hash (Kiev, counter + 1, Ll, L2, ...) 
where notation (counter + 1) indicates that the value of the 
counter is incremented by 1 each time the ICV is updated. It 
should be noted that the value of the counter needs to be 
stored in a secure memory in this configuration. 
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[0316] Moreover, in a configuration in which the ICV 

(Integrity Check Value) of a license cannot be stored in the 
same media as the license, the ICV (Integrity Check Value) of 
the license may be stored in a media different from the media 
for storing the license. 

[0317] Assume that a license is stored in a media with no 

protection against an illegal copy operation. Examples of such 
a media are a read-only memory and an ordinary MO disk. In 
this case, if an ICV (Integrity Check Value) is also stored in 
the same media, it is quite possible that an unauthorized user 
is capable of updating the ICV. It is thus feared that the 
safety of the ICV is not assured. In order to solve this 
problem, the ICV is stored in a safe media of the host machine 
and used for controlling operations to copy the license. 
Examples of the copy operation are operations to check in, 
check out and move the license. In such a configuration, it is 
thus possible to execute safety management of the ICV and 
check falsification of the license. 

[0318] Fig. 50 is a diagram showing a typical 

configuration implementing the scheme described above. In the 
typical configuration shown in Fig. 50, a media 2201 with no 
protection against an illegal copy operation is used for 
storing licenses 1 to 3 . Examples of the media 2201 are a 
read-only memory and an ordinary MO disk. On the other hand, 
an ICV (Integrity Check Value) for these licenses is stored in 
a safe media 2202 employed in a host machine which the user is 
not allowed to freely access. Thus, in this typical 
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configuration, the user is prevented from illegally updating 
the ICV (Integrity Check Value) . When a device on which the 
media 22 01 is mounted plays back information from the media 
2201, for example, a PC serving as the host machine of the 
device or a server may be configured to check ICVs for forming 
a judgment as to whether the media is allowed to play back. In 
such a configuration, it is thus possible to prevent an 
operation to play back an illegally copied or falsified 
license . 

[0319] In addition, a client provided by the present 

invention can also be implemented by an apparatus other than a 
so-called personal computer. Examples of an apparatus other 
than a so-called personal computer are a PDA (Personal Digital 
Assistant), a cellular phone and a game terminal. 
[0320] If the series of pieces of processing is 

implemented by software, a program composing the software can 
be installed from a network or a recording medium into a 
computer including embedded special hardware or into a 
computer of another type such as a general-purpose personal 
computer capable of carrying out a variety of functions by 
executing various programs installed in the personal computer. 
[0321] A recording medium provided separately from the 

main unit of the apparatus serving as a client or a server is 
distributed to users for presenting a program recorded in the 
medium to users. The recording medium can be a package medium. 
As shown in Fig. 2, examples of the package medium are the 
magnetic disk 41 including a floppy disk, the optical disk 42 
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including a CD-ROM (Compact-Disk Read-Only Memory) and a DVD 
(Digital Versatile/Video Disk) , the magneto-optical disk 43 
including an MD (Mini Disk) and the semiconductor memory 44. 
Instead of installing a program from a network or a recording 
medium, the program can be presented to a user by storing the 
program in advance in a recording medium embedded in the main 
unit of the apparatus. As shown in Fig. 2, examples of the 
embedded recording medium are the ROM 22 and a hard disk 
included in the storage unit 28. 

[0322] In this specification, steps describing a program 

stored in the recording medium can of course be executed 
sequentially one step after another in accordance with a 
written procedure. It should be noted, however, that the steps 
do not have to be executed sequentially but, instead, the 
steps may also include pieces of processing to be carried out 
in parallel or individually. 

[0323] In addition, it is desirable to also encrypt a 

program executed to implement processing related to security 
in order to prevent the processing of the program itself from 
being analyzed. For example, a program of processing carried 
out to execute an encryption process can be designed as a 
tamper resistant module. 

[0324] Furthermore, the information included in the 

header of content to specify a license for allowing the use of 
the content does not have to be a license ID for uniquely 
identifying the license. In the embodiment described above, a 
license ID is information for specifying a license required to 
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utilize content, information for specifying content the use of 
which is allowed by a certain license, and information for 
identifying a license requested by the client 1. Instead, a 
list of various kinds of attribute information related to the 
content may also be included in the content, and conditions of 
attributes of contents may also be included in a license for 
specifying the contents allowed to be used. In this case, 
attribute information included in the content is information 
for specifying a license for allowing utilization of the 
content and information for specifying content the use of 
which is allowed by a license in accordance with a condition 
equation included in the license. A license ID is information 
for uniquely identifying a license. In this way, content can 
be associated with a plurality of licenses so that the content 
can be issued in a more flexible manner. 

[0325] In addition, the technical term 'content- 

exchanging system' used in this specification means the entire 
system comprising a plurality of apparatuses. 

[0326] As described above, in accordance with the 

information processing apparatus and method provided by the 
present invention and the program for implementing the 
information processing method, encrypted data can be 
distributed with a high degree of freedom and, by acquiring a 
license provided separately from content, the user is capable 
of utilizing the content. As a result, a copyright can be 
protected and a proper usage fee can be collected without a 
hindrance to distribution of the content. 
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[0327] Although the invention herein has been described 

with reference to particular embodiments, it is to be 
understood that these embodiments are merely illustrative of 
the principles and applications of the present invention. It 
is therefore to be understood that numerous modifications may 
be made to the illustrative embodiments and that other 
arrangements may be devised without departing from the spirit 
and scope of the present invention as defined by the appended 
claims . 
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